Scheduled jobs reference

The cron process runs 79 job definitions. Processes and ports describes the process; this page describes the work.

The registry is built in backend/src/cron/index.ts. Every entry carries a name (the key the admin panel and the trigger endpoint use), a period and a function. period is a fixed interval in milliseconds, not a crontab expression. There is no 0 3 * * * anywhere in this platform: a job with a 24-hour period fires 24 hours after the scheduler started it, not at midnight, so a restart moves every daily job to a new hour of the day. Nothing in the admin panel or .env changes a period — it is a constant in the source.

17 jobs run on every install. The remaining 62 are gated on an enabled extension and are absent from the registry entirely when that extension is off. A short list on the cron console is not a fault; it is an install with few addons.

The 17 core jobs

These are registered regardless of which addons you own. category is normal for all of them.

The 62 addon jobs

Each block registers only when the named extension is enabled on Admin → System → Extensions. Toggling an extension does not need a restart — the scheduler re-evaluates gating every 60 seconds and logs Extension <name> enabled — scheduled cron <job> or Extension <name> disabled — stopped cron <job>.

"No error in the log" is not evidence a job ran

A job may refuse itself on the process it is registered in and still return normally. backend/src/cron/refusal.ts is the only sanctioned way for that to happen, and it is never quiet: every refusal lands in four places at once — sticky state on the job row, logger.error, the live log on the cron console, and an URGENT in-app plus email alert to every Admin and Super Admin.

The state is recorded on every refused tick. The three announcements are rate-limited to one per job per fifteen minutes, because the jobs that refuse tick every 5 to 60 seconds.

A refusal carries four fields, and the alert prints all four:

There is also a degraded variant. It means "running, but achieving nothing", not "not running": the handler executed and no tick was dropped, but its work has nowhere to land. The console shows those in warning colour rather than destructive, and the job's status stays reportable rather than refused.

The three refusal gates

backend/src/cron/mode.ts holds the three runtime tests. All three answer false immediately on a single-process (CRON_MODE=inline) install — none of them can fire there.

Symptom to job

Before you conclude a job is broken, confirm the scheduler itself is alive. A stopped cron app produces every one of these symptoms at once, and the job list keeps showing plausible "last run" times for 24 hours after it dies. That is what the scheduler console is for.

The API

The WebSocket at the same base path (/api/admin/system/cron) carries the live log, and is gated on view.cron too. Opening the console is what puts a browser in the relay audience, which is what makes the cron process start publishing ordinary log lines at all — the scheduler holds no sockets of its own, so it asks the web process whether anyone is looking before it builds a payload.

access.cron is the third key: it gates the page at /admin/system/cron. A role needs access.cron plus view.cron to read the console, and manage.cron on top to press Run now.