Schedules and close mode

Navigate: Configure → Schedules (/schedules).

Interval-based, not cron

A schedule is an interval plus a calendar envelope, not a cron expression. That shape exists because the scenarios that matter here — quarter-end, year-end, an audit period — are calendar-bounded, which cron expresses badly.

Field	Values	What it does
Interval value + unit	integer + minutes / hours / days / weeks	How often it runs.
Days of week	ISO 1–7, or empty for every day	Restricts to specific days.
Active start / end time	time of day	A daily window.
Effective from / until	date	Calendar bounds. This is how a "last five days of the quarter" schedule is expressed.
Window mode	auto / full	auto compares the incremental window; full forces a full-table comparison.
Priority	low / normal / high / critical	Ordering when the platform is congested. Resolved as the maximum of this and the platform floor.
Tags	list	Grouping used by close mode.
Enabled	on/off	Master toggle.
Runs at	date and time in the schedule's timezone	Where the series starts; see When does a schedule run?.

Worked examples

Scenario	Configuration
Hourly during business hours	1 hour · Mon–Fri · 06:00–20:00 · tag regular
Quarter-end nightly full sweep	1 day · effective over the last 5 days of the quarter · window_mode=full · tag quarter-end
Year-end audit	4 hours · effective 25 Dec – 15 Jan · priority critical · window_mode=full · tags year-end, audit
Ad-hoc only	no schedule — trigger manually

When does a schedule run?

A schedule's runs sit on a fixed timetable worked out from its settings alone: Runs at, the interval, the active window, the days of week and the effective dates. When it last ran does not move that timetable.

Runs at is a date and time in the schedule's timezone where the series starts. New schedules get "now" if you leave it empty.

Interval	When it runs
Minutes or hours, no Active Start	At Runs at, then every interval after it (for example Runs at 00:20, every hour: 00:20, 01:20, 02:20 and so on).
Minutes or hours, with an Active Start	Every day from Runs at's date: at Active Start, then every interval until Active End.
Days or weeks	Every N days (or weeks) counted from Runs at's date, at Active Start if you set one, otherwise at Runs at's time of day. A weekly schedule keeps its weekday; an every-2-days schedule keeps its odd/even days.

Runs never fall outside the active window, the selected days of week or the effective dates.

Daylight saving time

• Day and week schedules keep their clock time. A daily 08:00 run stays at 08:00 local time on both sides of a clock change.
• Minute and hour schedules keep their spacing. An hourly schedule runs every 60 minutes of real time, so it runs 25 times on the day the clocks go back and 23 times on the day they go forward.
• A time that does not exist (it falls in the hour the clocks skip) runs when the clocks have gone forward: 01:30 becomes 02:30 in London on the spring change day. A time that happens twice (the hour that repeats when the clocks go back) runs the first time it occurs.
• A short window, such as 08:00-09:00, still runs on the spring change day.

Restarts, edits and outages

• Restarting the platform or editing a schedule inside its active window does not start an extra run. The scheduler wakes, sees that the current slot of the timetable has already run, and goes back to sleep. (Before this change an edit or restart inside the window started a run immediately and shifted the schedule's timing to that moment.) An edit that changes the timetable itself, such as a new interval or Runs at, can start one run straight away if the change puts the schedule in a slot that has not run yet.
• Turning a schedule back on runs it at most once for the current slot, and only if that slot has not already run.
• After an outage the schedule runs once to catch up, if it comes back inside its active window, and then continues on its timetable.

Schedule overrides cannot loosen the mapping

A schedule may tighten max_lag_seconds and quiescence_seconds, never exceed the mapping's values. An override that would loosen the mapping's setting is skipped for that schedule and reported, not silently applied.

cdc_integration_mode cannot be changed by a schedule at all — it is mapping-level only.

Is the scheduler actually running it?

Saving a schedule writes the row and then asks the platform's workflow engine to start (or wake) the durable scheduler behind it. That second step is a network call, and it can fail on its own — leaving a schedule that looks enabled with nothing behind it. The Next Run column says so instead of pretending:

• Scheduler not running (red) — the last attempt to start this schedule's scheduler failed. Hover the badge for the reason. Check that the scheduler worker and Temporal are up; the platform re-tries every maintenance tick (about every five minutes) and the badge clears itself once they are reachable. Nothing is lost in the meantime except the runs in that window, and no data is compared while it shows.
• Syncing (amber) — written, not yet confirmed. Normal for a few seconds after a save, and for existing schedules just after an upgrade. If it persists for more than a tick or two, treat it like the red badge.

No badge means the scheduler is confirmed running.

Changing several schedules at once

Tick the schedules in the list to show the selection bar. Besides Enable and Disable, it offers Change frequency: set one "every N minutes / hours / days / weeks" on every selected schedule. Days of week, active hours and every other setting stay as they were, and schedule names are not changed - rename a schedule whose name states its old frequency.

Each schedule is saved on its own, exactly as if you had edited it, so each one is re-synced with its scheduler and audited. If a schedule was changed by someone else after the list loaded, it is not overwritten: the dialog lists it by name and the others are still updated. Reopen that schedule to review it.

Close mode

Navigate: Configure → Schedules → Close Mode (top right; requires schedule write permission).

Close mode is a bulk convenience toggle over tags, not a separate scheduling engine. It enables or disables every schedule carrying the given tags, and can optionally step priority up or down and apply the two tightening overrides.

The typical use is a period close: tag the schedules that should run harder at quarter end, enable them together on the first day of the close, and disable them together when it's over.

Using the screen

1. Pick the tags. Each tag chip shows how many schedules currently carry it. Selecting several tags targets the union of them; a schedule carrying two selected tags is still only acted on once.
2. Choose Enable or Disable.
3. Optionally adjust priority and the overrides (see below).
4. Apply. The result panel reports how many schedules changed, the per-tag breakdown, and — importantly — anything that was not applied.

The tag list is built from all your schedules, not just the ones currently matching the page's filters. A tag sweep does not silently exclude rows you have filtered out of view.

Priority boost

Priority moves in enum steps (−3 to +3, clamped at low and critical) rather than to an absolute value, so the relative ordering between your schedules is preserved — which is the point of a boost. +1 applied to a normal and a high schedule yields high and critical; it does not flatten them both onto one level.

Overrides, and why some are skipped

max_lag_seconds and quiescence_seconds are L6 (schedule) values, so they can only ever tighten what the mapping (L4) already allows. If the value you enter is looser than a given schedule's mapping, it is skipped for that schedule and counted.

Those counts are shown in the result panel, per setting — for example "Some overrides were not applied. max_lag_seconds: 4 schedule(s)." Read them. A skip is not an error; it is telling you those four mappings are already stricter than what you asked for, and their existing values were kept.

cdc_integration_mode cannot be changed by close mode at all — it is mapping-level only and needs an explicit config version change.

All close-mode changes are written to the audit log, including the boost and the skip counts.

Close mode is also available directly as POST /schedules/bulk-toggle if you would rather drive a period close from a script. Same contract, same response. The schedules list itself is cursor-paginated: pass the last row's name and schedule_id back as cursor_name / cursor_id to fetch the next page. Ordering is by lower-cased name, then schedule id.