Scheduled jobs
This page lists the jobs an installation runs, how to change or pause each one, and what catch-up after downtime does and does not do.
Before you begin
- A running installation (
pnpm os:statusshows it healthy).
What runs, and when
Times are the product defaults, in UTC. Your installation shows the saved schedule and the next run beside each job.
| Job | Default | What it does |
|---|---|---|
| Live traffic and counters | every 15 minutes | Refreshes the live Google Analytics and Search Console readings |
| Ad revenue | 10, 30 and 50 minutes past each hour | Checks for a new Mediavine revenue report when one is due |
| Subscription revenue | 20 past each hour | Records each completed UTC day's Stripe sales less refunds for the site that names the account; asks Stripe only when a day is missing |
| Data freshness checks | every hour | Flags a site whose report is late or whose connection stopped |
| Operator notifications | 5 past each hour | Sends what changed since its last run |
| Nightly reports | 02:30 | Collects the daily provider reports, including Bing Webmaster |
| NoticeOS report | 03:00 | The installation's own report about itself |
| Outcome checks | 03:30 | Reads the follow-up window of each shipped change |
| Search accessibility checks | 04:00 | Robots, sitemap, indexing and security-header checks, and a read of the light and dark icons each site's home page declares |
| Backups | 04:00 | The nightly backup; see Backups and restore |
| Page speed | 04:15 | Reads each site's Chrome UX Report page speed; runs once a Chrome UX Report key is connected |
| Clarity recordings summary | 04:30 | Summarises Microsoft Clarity data |
| Traffic and search archives | 12:15 | Archives the day's Google Analytics, Search Console and Bing reports |
| Product analytics archives | 12:30 | Archives PostHog reports |
| Search rankings and backlinks | Mondays 12:45 | The weekly DataForSEO collection. This one spends money; see Budgets |
| Local research summaries | 13:10 | Refreshes each site's local research files and publishes the summary |
| Task board refresh | every minute | Copies the task service's current tasks into the store for the Tasks page |
| Task service health | every 15 minutes | Checks that the task service responds |
| Task project checks | 5 past each hour | Checks every declared task project still exists |
| Search review tasks | 25 past each hour | Files a review task when a new search collection arrives |
| Unpublished commit checks | 40 past each hour | Files a task when a project has commits that are not pushed |
| Outcome task updates | 50 past each hour | Updates the tasks that track an outcome window |
Catch-up after downtime
While the service is down, a due job is skipped and recorded. At the next start the service runs at most one missed run per job, and only when the missed run is recent enough:
| Jobs | Caught up when the last due run is within |
|---|---|
| Live traffic and counters | 1 hour |
| Data freshness checks, Operator notifications | 2 hours |
| Daily collections, archives and backups | 36 hours |
| Ad revenue | 36 hours, and only if a report is actually due |
| Search rankings and backlinks (weekly) | 8 days |
The pass runs cheapest job first, so a reboot is not a burst of provider calls. It never replays every missed run: one missed day of a 15-minute job is one refresh, not 96. A failed run still counts as a run, so catch-up never loops on a failure.
Some things are never caught up, by design: database migrations, restores, settings imports, deployments and any change to alert rules or measurement. Those are your explicit actions and stay that way.
Change a schedule
- Open System health > Background operations (
/health/operations). - Select the job, then Edit schedule.
- Change the frequency, local time or weekday, or set the job to Paused. The editor previews the next three runs and saves with Undo. Restore default removes your override.
A collection fed by a provider connection is changed with that connection: open Integrations, select the connection, and use its Manage panel. A collection no connection feeds is changed under Settings > Data collection.
The Workflows page (/workflows) lists the operator automations with their history; their schedules are edited the same way. Saved schedules are kept across restarts and deploys. A time you save uses your browser's time zone; the product default is UTC.
Pausing fully stops a job
A paused job does not run on its schedule, is not caught up after downtime, and blocks Start collecting on a connection panel until you resume it.
Run one job by hand
In the checkout, run the jobs scheduled on that expression:
shpnpm os:run-job -- "15 12 * * *"
A connection's Start collecting button runs that provider's first collection at once and previews the cost of a metered step first.
Verify
- The job's row under Background operations shows the saved schedule and the next run.
pnpm os:logs -- noticeosshows each job firing, including what the catch-up ran after a restart.pnpm os:run-jobprints the jobs it runs when you pass an expression.
If it didn't work
pnpm os:run-jobrejects the expression and prints it: no job runs on it. Use one of the expressions the command prints.- Start collecting is blocked on a connection panel: the job is Paused. Resume it under Background operations first.
- A provider job records paused before the monthly data cap: the metered spend would cross the cap. Raise it under Settings > General > Budget, or wait for next month. See Troubleshooting.
The runner's contract, including the port map and the exact recovery policy, is on GitHub: https://github.com/notice-cx/NoticeOS/blob/main/scripts/README.md#bounded-catch-up-after-downtime.