Uptime monitor and status page - checking from outside

Why this design

Every company with customers eventually needs two things: to find out it is down before customers tell it, and somewhere to say so that keeps working while it is down. Both sound trivial - curl the site every minute, host a page - and both fail in instructive ways. The monitor fails by measuring from the wrong place or by crying wolf; the status page fails by sharing infrastructure with the thing it reports on. This board is about where to stand when you measure, how to decide a failure is real, and how to keep the message up when everything else is not.

What you will learn

• Why internal health checks miss the outages customers see, and what an outside-in synthetic check actually exercises: DNS, TLS, edge, application.
• Quorum across regions and consecutive failures: the arithmetic that trades detection time against false pages.
• Fate sharing: why the status page runs on a different provider, CDN, DNS and domain.
• Why the status page is static, and how a 100x read spike during an incident becomes a non-event.
• Who watches the watcher: a dead-man's switch for the monitor itself.

How to read this board

1. Press Play and follow the walkthrough: CONTROL PLANE top left, PROBES in the middle, YOUR SERVICE on the right.
2. Then DECIDE under the probes, where three opinions become one verdict.
3. Then RESPOND on the left and the STATUS PAGE band on the right - note it shares nothing with YOUR SERVICE.
4. 1 · Requirements to 6 · Deployment in the written band, then the DATA MODEL.
5. Then argue with the tension: the board measures reachability and calls it availability.

Ask these before drawing anything

• What does "up" mean for this product? A 200 from the homepage, or a user able to log in and load their data? The answer decides whether checks are pings or scripted journeys.
• How fast must we know? Detection time is roughly interval times consecutive failures needed. Thirty second checks needing two failures is about a minute.
• How much does a false page cost? A team paged at 3am for a probe network blip twice a week will start ignoring pages, which is worse than no monitor.
• Who writes on the status page, and is anything automatic? Auto-posting "investigating" is fast and occasionally wrong in public.
• Is the status page a contract? If an SLA credit depends on it, its history must be accurate and immutable.

Functional

• Define monitors: URL or scripted check, interval, regions, assertions (status code, body contains, TLS expiry over 14 days, latency under a threshold).
• Run every monitor from at least three regions outside our cloud account.
• Open an incident when a quorum of regions fails on consecutive checks; resolve it when they recover.
• Page on-call; post an automatic "investigating" on the affected components; let a human write updates.
• Publish a public status page with components, current incidents and 90 days of history, and email or webhook subscribers.

Non-functional

• Detection: a full outage opens an incident within 90 seconds.
• False pages: fewer than one per month per service from probe-side causes.
• The status page is available at 99.99 percent and is independent of every component it reports on.
• The page serves 5,000 requests a second during an incident with no origin scaling.
• If the monitor itself stops producing results, someone is paged within five minutes.