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

  1. Change the crontab so consecutive executions are at least minimum_interval apart (e.g. '*/5 * * * *' for a 300s minimum)
  2. If your deployment can sustain the load, lower ALERT_REPORTS_MINIMAL_INTERVAL in superset_config.py
  3. 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
  4. 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

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


AI-assisted analysis of apache/superset@f4587218dd (2026-08-14). Data as JSON: /api/errors/88911f9e60c60eee. Report an issue: GitHub.