Scheduled jobs reference

The cron process runs 93 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.

22 jobs run on every install. The remaining 71 are grouped into 18 extension buckets and are absent from the registry when that extension is off — with eleven exceptions that keep running because they settle money customers are already owed, listed under Jobs that survive a disable. A short list on the cron console is not a fault; it is an install with few addons.

The 22 core jobs

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

The 71 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>.

Jobs that survive a disable

Disabling an extension stops its jobs within the minute — with eleven exceptions. A job that settles money the platform already owes is scheduled on the disabled branch, and scheduled again after a restart:

processPendingEcoWithdrawals, ecosystemWithdrawRecon, processAiInvestments, runFxExecutionReconciler, processIcoOfferings, processStakingPositions, processRealStakingBatches, p2pTradeTimeout, expireOffers, processClosedCopyTrades, reconcileCopyTradingOrders.

The addon's routes still close, so nothing new can start. Two consequences for this page: a disabled addon can still show rows on the cron console and that is correct, and switching an addon off is not a way to stop one of these eleven. The only way is stopEverything on the extension toggle, which records the addon in the cronHardStoppedExtensions setting and brings them down with the rest. If that setting cannot be read, the jobs keep running — the list fails open towards the people who are owed.

Why each of the eleven is on the list, and what stopped being settled before they were, is in Bicrypto 6.7.6.

"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.

A cron module that fails to load

The three gates below are about which process a job is in. There is a fourth producer of a refusal that is not: every addon job reaches its handler through a dynamic import, and an import can fail on an install that owns the addon.

safeImportModule returns the same null for "the customer never bought this addon" and for "the addon is installed and its module threw on import". Collapsed that way, a broken import made the wrapper return without throwing, lastRunError stayed null, and the admin table showed the job completed with a 100% success rate. It was observed on a live install, with all six on-chain staking jobs reading green while the module had never loaded once:

CRON [IMPORT] Failed to load module @b/api/(ext)/staking/utils/real/cron:
  Cannot find module '.../backend/dist/src/blockchains/network-fee-tracker'

addonCronModule in backend/src/cron/index.ts now separates the two. An absent addon stays silent — a customer who did not buy staking is not suffering a fault. An addon that is on disk and did not load gets a standing refusal on every job behind that module, so those rows read REFUSED rather than completed, and the reason carries the loader's own message verbatim.

The alert is keyed on the module rather than the job, because AI Support and copy trading each put eight jobs behind one import, the AI market maker seven and on-chain staking six — keyed per job, one failed import would mail every administrator eight identical URGENT alerts every fifteen minutes. The per-job refusal state is not keyed that way, so every affected row still shows its own refusal on the console.

There is nothing to change in the deployment shape here; the fix is in the reason. A missing dependency usually means an addon built against a newer core than the one installed. A syntax error or a throw during module init is a defect in that addon's build. Restart the scheduler once the module loads.

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.