Schedules and run windows
How often a rule runs, whether it lands on the clock like cron, and the hours it is allowed to run at all.
Two separate settings: how often the rule runs, and when it is allowed to.
Run every N minutes
The interval. The worker ticks every minute and evaluates rules that are due.
Run at: drifting, or on the clock
| Mode | Behaviour |
|---|---|
| whenever the interval is up (default) | Due once the interval has passed since the last check, wherever that lands |
| on the clock, like cron | Lands on wall-clock boundaries: :00 for hourly, the quarters for 15 minutes, local midnight for daily |
A drifting hourly rule created at 14:37 runs at 15:37, 16:37, 17:37 — never on the hour, and drifting a little further each day as each run's own few seconds accumulate. Nobody chose 14:37; it is simply when the rule was saved.
Clock alignment makes the boundary the schedule.
Offset
Clock-aligned rules take an offset in minutes. An hourly rule with an offset
of 10 runs at :10.
Use an offset whenever the data lands a few minutes after the hour. Reading a
table at :00 while it is still being written reports a shortfall that is not
one — and then recovers by itself at :05, which is the exact pattern that
teaches a team to ignore a rule.
Timezone
The rule's timezone governs both the clock boundaries and the run window below.
"Hourly, Asia/Baku" means the top of the hour there. An unknown timezone falls
back to UTC — never to the server's local time, which would shift every window
by an unpredictable amount.
Daily rules count calendar days, so a daily rule crosses a daylight-saving change once, not twice.
What happens after an outage
A rule that missed three boundaries while the backend was down runs once, now — and the next run is back on the clock. Missed boundaries are not replayed: the first two answers would be stale, and three catch-up runs against the warehouse would raise three alerts about one thing.
Run window
A rule can be restricted to certain days and hours. Outside it, the query is not run at all.
| Setting | Meaning |
|---|---|
| Days | Which weekdays. Empty means every day |
| From / To | Minutes since midnight in the rule's timezone. Equal values mean all day |
| Timezone | IANA name, e.g. Asia/Baku. Empty means UTC |
A window where From > To wraps midnight — 22:00 → 06:00 is a real
maintenance window and is supported directly rather than needing two rules.
Why a window, rather than a silence
A reconciliation that only means anything after the nightly load has two problems if it runs every five minutes regardless: the warehouse does the work three hundred times for one meaningful answer, and the rule fires at 04:10 against a half-loaded table, wakes somebody, and has recovered by the time they reach a laptop.
The second is worse, because it teaches the team that this rule is noise.
What a closed window does not do
It does not resolve anything. Outside the window the rule is not evaluated, so there is no reading — and no reading is not evidence of recovery. An alert raised at 18:00 is still open at 09:00 the next morning.
A boundary missed because the window was shut is still waiting when the window opens: the rule runs immediately rather than waiting for the next boundary.
Next run
The rule list and detail page show when the rule will next be evaluated, in words and as a timestamp. That number is computed by the same function the worker uses — it is not the page's own arithmetic, so the two cannot disagree.
Where this behaviour lives: backend/internal/domain/dwh_cadence.go, backend/internal/domain/dwh_schedule.go. If the code and this page disagree, the code is right — please fix the page.
Part of Data warehouse — Querying the warehouse, and alerting on what the query returns.