Checks and scheduling

Set checks.interval to decide when monitors run, and displayDays to control how much history visitors see. The summary and cleanup jobs have their own schedules. Define all three cron expressions here, then keep your platform's triggers in sync with them.

checks: {  interval: "*/5 * * * *",  retentionDays: 90,  displayDays: 90,  summaryCron: "10 0 * * *",  cleanupCron: "0 3 * * *",},

The three jobs

After a job finishes, it invalidates the snapshot cache. The next render reads the updated data.

Cron syntax

Heyo Status evaluates standard five-field expressions — minute, hour, day-of-month, month, day-of-week — in UTC. Supported field syntax is *, a number, a a-b range, a , list and a /n step. Sunday may be 0 or 7. When both day-of-month and day-of-week are explicit, they are combined with OR, as in classic cron.

Choose how much history to show

displayDays and retentionDays answer different questions:

• displayDays is what a visitor sees. It is the width of the uptime grid and the range the snapshot query reads.
• retentionDays is what the database keeps. Raw rows older than it are deleted, as are daily summaries older than the same boundary.

Validation rejects displayDays > retentionDays because the page would ask for days the cleanup job already removed.

// A 30-day page backed by a year of history for internal analysis.checks: { displayDays: 30, retentionDays: 365 }

Storage grows with monitors × checks per day, until compaction turns a day into one row per monitor. At a five-minute interval that is 288 raw rows per monitor per day, collapsing to one summary row.

Snapshot cache

Reading the whole history window on every page view is wasteful. The runtime keeps a snapshot in memory for a short time instead.

cache: { snapshotTtlMs: 30_000 }

• 0 disables caching entirely; every read hits the database.
• The maximum accepted value is 3600000 (one hour).
• Concurrent misses are collapsed into a single database read.
• Passing an explicit clock — getSnapshot(new Date(...)) — always bypasses the cache, which keeps tests deterministic.
• runChecks, summarize, cleanup and every admin mutation invalidate it. After an out-of-band write, call statusPage.api.invalidate() yourself.

Running the schedule

# Runs the framework dev server and all three jobs.heyo-status dev -- next dev

The platform configuration must match the configuration file. On Cloudflare, cloudflareCronExpressions(statusPage) returns exactly the list wrangler needs, and the Worker handler matches an incoming trigger against the three expressions — an unknown trigger is deliberately a no-op, so stale cron configuration during a deploy is harmless.