> ## Documentation Index
> Fetch the complete documentation index at: https://docs.happyuptime.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

**[Monitors](/concepts/monitors)**

HTTP, TCP, DNS, ping, keyword, and heartbeat checks executed on a 1-minute cron from 6 regions.
  **[Incidents](/concepts/incidents)**

Auto-created when a monitor's confirmed status flips to down or degraded. Severity inferred from how many regions fail.
  **[Status pages](/concepts/status-pages)**

Server-rendered, edge-cached, accept custom domains, ship with three templates.
  **[On-call](/concepts/on-call)**

Multi-layer schedules with rotations, restrictions, fixed shifts, overrides, and escalation policies.
  **[Alerts](/concepts/alerts)**

Slack, Discord, webhook, Telegram, email — with quiet hours, mute, and on-call routing.
  **[Dependencies](/concepts/dependencies)**

Track the third-party services you depend on (AWS, OpenAI, Stripe…) and surface vendor outages alongside yours.

## 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

**[REST API](/api/overview)**

Bearer-token auth (`hu_…`). Versioned at `/api/v1`.
  **[CLI](/cli/install)**

`happy` and `happyuptime` binaries. Mirrors every endpoint.
  **[Dashboard](https://happyuptime.com/dashboard)**

React SPA at happyuptime.com.

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.