What it is
The Scheduling & Recurrence engine is the shared substrate behind anything in the platform that runs on a repeating schedule - delivering a report, re-running an access-review cycle, sweeping for due dates. Rather than every feature inventing its own timer, they register a scheduled job against this engine, and a single sweep fires them when they are due.
It provides three things:
- DST-safe recurrence math - it computes the next fire time for hourly, daily, weekly, monthly, quarterly, and yearly cadences, holding the intended wall-clock time across daylight-saving transitions in the job's timezone.
- A generic scheduled-jobs store - each job records its type, a human-readable recurrence, an enabled flag, the next and last fire times, a fire count, and the last result.
- A handler registry - a feature registers a handler for its job type; the sweep invokes that handler with the job's payload when the job is due.
How jobs run
A sweep runs every 15 minutes. It finds every enabled job whose next fire time has passed, invokes the registered handler for that job's type, records the result (ok / error / skipped), and advances the job to its next fire time. Jobs are registered in code by the features that own them, not configured by administrators: there is no create, delete, run-now or disable surface, in the product or over the API. The engine advances each job on its own schedule and there is nothing to operate. (The HTTP routes that once implied otherwise were removed in ADO #2130 — nothing had ever called them, and their list was tenant-scoped over jobs owned by the platform, so it returned empty for every customer.) A job can in principle be disabled in the store, and re-enabled later.
The recurrence is described in plain language wherever a job is shown - "Daily at 06:00 UTC", "Weekly on Mon", "Quarterly on day 1" - so the cadence is readable at a glance rather than as a cron string.
Where you see it
The engine is internal infrastructure. It is not a feature you configure, and there is no page for it.
Two platform-owned sweeps run on it today, daily for every organization: control-test-overdue and governance-meeting-due. Both are owned by TATER rather than by your org, so they do not appear in an org-scoped listing and cannot be changed from the product.
It previously said the engine backs “scheduled report delivery and recurring review cycles”. Neither does: insights report scheduling carries its own timer and contains no reference to this engine, and access-review recurrence is implemented separately as recurrenceDays on the campaign. Corrected 2026-08-22 (ADO #2130).
MCP tool reference
| Tool | Purpose |
|---|---|
list_scheduled_jobs | List the organization's recurring scheduled jobs - job type, human-readable recurrence, enabled state, and next fire time. Optional job-type filter. Auditor+. |
Related
- Reports guide - report scheduling is a SEPARATE mechanism with its own timer, not a consumer of this engine
- GRC guide - recurring access-review cycles and due-date sweeps
- MCP setup - connecting Claude Desktop / API to TATER