How Happy Uptime works
A 5-minute tour of the system that powers your monitoring, status pages, and on-call rotations.
How Happy Uptime works
Happy Uptime is built on Cloudflare's edge — Workers, Workflows, D1, KV, R2, Durable Objects. Every check, every alert, every page render runs at a colo close to you or your customer. There's no central server to scale, no region to fail.
The pieces
The flow of a check
Cron fires (every 60s)
A scheduled Worker queries the D1 database for monitors due for a check. Each gets dispatched to a CheckRunnerWorkflow instance.
Workflow executes per-region
The workflow runs the configured probe (HTTP request, DNS lookup, TCP connect…) from each region in parallel. Captures DNS / connect / TLS / TTFB / transfer timings.
State machine resolves status
Per-region results aggregate into a confirmed status: up / degraded / down. Configurable confirmation periods prevent flap.
Side effects run
On status changes: dispatch alerts, auto-create / resolve incidents, capture failure screenshots, update edge-cached status pages, broadcast to dashboard via WebSockets.
Where data lives
| Layer | Used for |
|---|---|
| D1 (SQLite at the edge) | All structured data: monitors, incidents, schedules, alerts, audit log |
| KV | Rate limit counters, mute keys, OAuth state, edge-cache invalidation |
| R2 | Screenshots (failure + baselines), assets |
| Durable Objects | Real-time WebSocket dashboard updates |
| Workflows | Long-running multi-region checks + dependency scanning |
How you talk to it
Every feature in the dashboard is also in the REST API — the dashboard is an API client. If you can do it in the UI, you can script it.