Skip to content
schedules
Automation

Schedules

A schedule is what turns a report into something that happens on its own. It binds a report to a cron expression and a timezone; the report holds the query, the output format, and the delivery routes.

Read
6 min
Module
Schedules

How a schedule runs

Each schedule carries a nextRunAttimestamp. A background worker claims due schedules, runs the report’s query against its connection, records the result as a run, and hands the result to every delivery route on the report. If the query fails, the run is stored with its error and the failure alert fires — the schedule itself is not disabled, so a transient outage does not silently stop your reporting.

  1. 01Build the report firstA schedule points at a report, not at a query directly. The report is what carries the query, the output format, and the delivery routes.
  2. 02Set the cadenceA standard 5-field cron expression. Each schedule stores its own timezone, so two schedules on one report can fire in different regions.
  3. 03Preview the next runsBefore saving, the editor expands the expression and shows the next firing times, so a wrong field is caught before it costs you a night.
  4. 04ActivateA schedule is active by default. Every delivery route on the report fires on every run.

Cron expressions

Schedules use five fields: minute, hour, day of month, month, day of week. The expression is evaluated in the schedule’s own timezone — stored on the schedule and defaulting to UTC — so a 07:00 report stays at 07:00 across daylight-saving changes, and the same report can fire at local 07:00 in two regions from two schedules.

ExpressionMeaning
0 7 * * 1-5Every weekday at 07:00
*/15 * * * *Every 15 minutes
0 9 1 * *First day of the month at 09:00
0 */6 * * *Every 6 hours, on the hour
30 23 * * 0Sundays at 23:30
Overlapping runs are not suppressed.If a run is still executing when the next tick arrives, the tick fires anyway and a second run starts. Give a schedule an interval comfortably longer than the query’s worst-case duration, or a slow query will pile up behind itself.

Parameters

Parameters are declared on the query, not on the schedule — a schedule has no parameter store of its own. An unattended run therefore uses the defaults the query declares. To run the same SQL with different values on different cadences, give each variant its own query (or its own report over a parameterised query) and schedule those separately.

This is worth knowing before you design around it: changing a query’s default parameter values changes what every schedule over that query sends on its next run.

Pausing and running out of band

Note where each control lives. Activation is a property of the schedule; running now and pausing delivery are operations on the report.

Deactivate a schedule
Clearing the schedule’s active flag stops it claiming ticks while keeping its configuration and history. Use it during a migration instead of deleting.
Run the report now
Reports expose a run action that executes immediately and independently of nextRunAt. It needs the reports:run permission, which viewers hold.
Maintenance windows
A maintenance window suppresses the alerting that failures would raise, without stopping the schedules themselves.

Plan limits

Schedules count against your plan. Free workspaces get 5; Pro and Business are unlimited. A schedule that would exceed the limit is rejected at creation with a clear error rather than being created and silently skipped.