Tool

Uptime monitor

Probes endpoints from Cloudflare's edge, keeps a week of history, and publishes the ones you choose to /status.

What a monitor asserts

Only public URLs. Private and loopback addresses are rejected — and the Worker could not reach them anyway.

Scheduling

Checks are triggered over HTTP rather than by a Cloudflare Cron Trigger. The reason is structural: the Astro Cloudflare adapter generates the Worker entrypoint and exports only fetch, so there is nowhere to hang the scheduled handler a cron trigger calls. Rather than fork the adapter's build for it, the runner is an endpoint:

POST https://tesseract.page/api/uptime/run
x-cron-key: <CRON_SECRET>

Set the secret once:

npx wrangler secret put CRON_SECRET

Then point anything at it on a schedule — a GitHub Actions workflow, a separate Cloudflare Worker with a cron trigger, cron-job.org, or a machine you already own:

*/5 * * * * curl -fsS -X POST -H "x-cron-key: $KEY" https://tesseract.page/api/uptime/run

Each call probes every monitor whose interval has elapsed, up to 20at a time, concurrently. Calling it more often than your shortest interval costs nothing — monitors that are not due are skipped.

Without a scheduler

It still works, just lazily: opening /status kicks off any checks that are due in the background. Good enough to be useful, not good enough to catch an outage nobody was watching for.

History

Every probe is one row: timestamp, ok, status, latency, error. Rows older than 7 days are pruned on each run, so the table stays a fixed size no matter how long it runs. Uptime percentages are computed in SQL over that window.

The status page

Monitors are private by default. Mark one public and it appears on/status with its 24-hour and 7-day availability and a strip of recent checks — a status page is a map of your dependencies, which is not something to publish by accident.

Adding and reading monitors is admin-only. The status page is not.

Esc