Schedules

A schedule answers one question: when does the scheduler re-run this dashboard's SQL? Everything else on this page is a consequence of how that question is stored and how the scheduler sweeps.

Cadences and intervals

A schedule is a time unit plus a multiplier, not a free-form expression. There is no cron string.

Cadence	Multiplier allowed	Anchors it takes
manual	none	none
hourly	every 1, 2, 3, 4, 6, 8, or 12 hours	an optional hour
daily	every 1 to 30 days	an optional hour, with a timezone
weekly	every 1 to 4 weeks	a day of week, an hour and a timezone, all three or none
monthly	every 1 to 12 months	a day of month, an hour and a timezone, all three or none

manual means the dashboard only refreshes when a person or a tool asks it to. It is not a degraded state: a dashboard with no schedule keeps its URL, its versions, its thumbnail and its share link forever.

The hourly multipliers are the divisors of 24, so "every 5 hours" is refused. The reason is that a divisor keeps the daily hour grid clean and repeating: every 6 hours means the same four times every day, where every 5 hours would drift through the day and mean a different set of times each day.

Day of month is capped at 28. This is a deliberate clamp, not an oversight: you cannot ask for the 31st, because February would silently skip. If you need the end of the month, take the 28th.

Days of the week are numbered from 0 for Sunday.

Sub-hourly

Below hourly there is one more option: every 15 or 30 minutes. It is a refinement of hourly rather than a separate cadence, and it comes with three conditions:

• it takes no anchors at all, because it runs on an absolute minute grid
• it is personal dashboards only today
• it is set in the web app, not through your AI tool

That last point matters if you are asking an AI to set it up: the scheduling tool it has does not expose a sub-hour argument, so it cannot do this even if it says it can. Set it on the Schedules page.

Anchors and timezones

An anchor pins a cadence to a wall-clock moment: "daily at 09:00 in America/New_York" rather than "every 24 hours from whenever this was armed".

Timezones are real IANA zone names. The anchor is interpreted in that zone, and the conversion to an absolute instant happens after the period arithmetic, which is what makes daylight saving behave correctly.

Without an anchor a cadence falls back to a plain interval from the last run: plus one day, plus seven days, plus thirty days. Note that unanchored monthly is a flat 30 days rather than a calendar month.

The precision you actually get

This is the part most likely to look like a bug, so it is worth stating plainly.

Dashies schedules to the minute you pick and starts the run within about half an hour of it. Usually much sooner.

Two things separate the nominal time from the actual one:

The sweep grid. The scheduler sweeps every 15 minutes, so a 09:00 run starts at the first sweep at or after 09:00.

Anti-herd jitter. Each dashboard carries a stable offset of 0 to 14 minutes, derived from its own id. It exists so a thousand dashboards all set to "daily 09:00" do not hit their warehouses simultaneously at 09:00. It is stable per dashboard, so a given dashboard always drifts by the same amount.

The jitter lives only in the sweep's selection, never in the stored next-run time. The "Next refresh" the web app shows you is the nominal instant, exactly 09:00, with no jitter baked in, so the displayed value and the stored value agree byte for byte.

The practical reading: a dashboard ten minutes past its nominal time is healthy. The web app agrees with you about this and does not call a run late until it is more than 20 minutes past, precisely because a perfectly healthy dashboard is legitimately past its nominal time for up to fifteen minutes every cycle.

Sub-hourly is tighter: a 5-minute grid plus 0 to 2 minutes of jitter.

If you need a number to the second, refresh on demand rather than tightening the cadence.

Daylight saving

For an anchored schedule, the period is added on the local date and only then converted to an absolute instant. That gives the behaviour you want:

• "Daily 09:00 America/New_York" stays 09:00 local across a daylight-saving change. It does not drift to 08:00 or 10:00.
• On the transition day itself the real gap between two runs is 23 or 25 hours. That is the correct consequence of keeping the wall-clock time fixed, and it is accepted rather than corrected.
• A wall time that does not exist, in the spring-forward gap, or that happens twice, in the autumn repeat, is normalized silently. A run is never lost and never doubled.

Sub-hourly and unanchored hourly are unaffected, because they are defined on absolute instants rather than wall-clock times.

The web app's preview of the next run implements the same conversion, so the time it shows you and the time the run fires agree across a transition.

What happens when a run fails

A failed scheduled run is not abandoned and not retried immediately. The next attempt is pushed out by 5 minutes doubled per consecutive failure, capped at one full period of the dashboard's own cadence. So the retries go 5 minutes, 10, 20, 40, and so on, and a permanently broken daily dashboard settles into retrying about once a day rather than ninety-six times.

A success resets the counter and re-anchors the schedule normally.

A failing dashboard stays in the sweep. It is the backoff, not exclusion, that bounds the retry rate, which is why pausing is the way to stop retries rather than waiting for it to give up.

Two other outcomes are not failures and are labelled differently:

• No change. The run succeeded and the numbers came back identical. Your data genuinely did not move.
• Skipped. The write collided with a republish that landed between the read and the write. Nothing is lost; the next run picks up the new body.

Refreshing on demand

Three ways to ask for a refresh now: the web app, your AI tool, and a headless HTTP endpoint. All three run the same recompute, all three require a paid plan, and all three share one property worth relying on: an on-demand run never pushes out the scheduled slot. Refreshing at 08:55 does not cancel the 09:00 run.

Three differences to know:

• Only the web app works on a workspace dashboard. Asking your AI tool to refresh one is refused, and so is the HTTP endpoint; both are personal dashboards only. On a team dashboard, "Refresh now" in the app is the path.
• The AI tool and the HTTP endpoint coalesce within 60 seconds. If a refresh already ran in the last minute, they report the data as already fresh rather than running again. A recent failed attempt does not coalesce, because the data is still stale and reporting it fresh would be a lie.
• The web app's "Refresh now" does not coalesce. Two clicks five seconds apart run twice.

The receipt you get back is metadata only: how many rows, how long it took, whether the numbers changed. Never the data itself.

Next

Plans and what is gated, since most of this page needs one.