apache/superset · error · ReportScheduleFrequencyNotAllowed
%(report_type)s schedule frequency exceeding limit. Please c
Error message
%(report_type)s schedule frequency exceeding limit. Please configure a schedule with a minimum interval of %(minimum_interval)d minutes per execution.
What it means
Raised by ReportScheduleCommand.validate_crontab_logic when a report/alert crontab fires more frequently than ALERT_REPORTS_MINIMAL_INTERVAL allows. The code iterates the next 60 (or 24) cron matches with croniter and measures the gap between consecutive executions; any gap below minimum_interval (only enforced when >= 120 seconds) triggers the error. It exists to prevent users from scheduling reports every second/minute and flooding the screenshot worker and email infrastructure.
Source
Thrown at superset/commands/report/base.py:356
"Invalid value for %s: %s", config_key, minimum_interval, exc_info=True
)
return
# Since configuration is in minutes, we only need to validate
# in case `minimum_interval` is <= 120 (2min)
if minimum_interval < 120:
return
iterations = 60 if minimum_interval <= 3660 else 24
try:
schedule = croniter(cron_schedule)
current_exec = next(schedule)
for _i in range(iterations):
next_exec = next(schedule)
diff, current_exec = next_exec - current_exec, next_exec
if int(diff) < minimum_interval:
raise ReportScheduleFrequencyNotAllowed(
report_type=report_type, minimum_interval=minimum_interval
)
except CroniterBadDateError as ex:
raise ReportScheduleCrontabNotValidError(
cron_schedule=cron_schedule
) from ex
View on GitHub (pinned to f4587218dd)
Solutions
- Change the crontab so consecutive executions are at least minimum_interval apart (e.g. '*/5 * * * *' for a 300s minimum)
- If your deployment can sustain the load, lower ALERT_REPORTS_MINIMAL_INTERVAL in superset_config.py
- If the check should not apply (minimum_interval < 120), verify the config value actually reached the worker; a stale webserver/worker holds the old value
- Simulate the schedule with croniter locally ('for _ in range(60): next(it)') to confirm the smallest gap before resubmitting
Example fix
# before crontab = '* * * * *' # every minute; fails when min interval is 300s # after crontab = '*/5 * * * *' # every 5 minutes; passes a 300s minimum
Defensive patterns
Strategy: validation
Validate before calling
from croniter import croniter
from datetime import datetime
def crontab_meets_minimum(crontab: str, minimum_interval: int) -> bool:
if minimum_interval < 120:
return True
it = croniter(crontab, datetime.utcnow())
prev = next(it)
for _ in range(60 if minimum_interval <= 3660 else 24):
nxt = next(it)
if (nxt - prev).total_seconds() < minimum_interval:
return False
prev = nxt
return True
assert crontab_meets_minimum('*/5 * * * *', 300) Type guard
def is_valid_schedule(crontab: str, minimum_interval: int) -> bool:
return croniter.is_valid(crontab) and crontab_meets_minimum(crontab, minimum_interval) Try / catch
try:
CreateReportCommand(user, payload).run()
except ReportScheduleFrequencyNotAllowed as ex:
# show minimum interval to user, request a sparser crontab
show_error(f'Schedule too frequent: minimum {ex.minimum_interval}s between runs') Prevention
- Mirror Superset's croniter gap-check client-side before submitting schedules
- Keep ALERT_REPORTS_MINIMAL_INTERVAL documented in your internal scheduling guide
- Never generate per-minute crontabs programmatically without checking the configured minimum
When it happens
Trigger: POST/PUT to /api/v1/report/ or /api/v1/alert/ with a crontab like '* * * * *' (every minute) while ALERT_REPORTS_MINIMAL_INTERVAL is set to 300 or higher. Any schedule whose simulated next executions include a gap smaller than the configured minimum, e.g. '*/2 * * * *' with a 360-second minimum.
Common situations: Operator raises ALERT_REPORTS_MINIMAL_INTERVAL to protect workers and pre-existing tighter schedules start failing validation; migrating schedules from another tool with minute-level cadence; testing with aggressive crontabs in a dev instance with a hardened config.
Related errors
- Invalid crontab schedule: %(cron_schedule)s never matches a
- Report Schedule executor user %(username)s was not found.
- Report Schedule execution failed when generating a screensho
- validation_error
- security_error
AI-assisted analysis of apache/superset@f4587218dd (2026-08-14).
Data as JSON: /api/errors/88911f9e60c60eee.
Report an issue: GitHub.