Uptime status poster
A small system that checks the handful of journeys customers depend on, from several regions, and publishes a status page hosted somewhere entirely separate from the thing it reports on. It drafts an incident and a person publishes it. Seven posts on the same system — one diagram at a time — with a cost breakdown and an engineering reference at the end.
- 01
An uptime status poster on AWS for a few dollars a month
The whole system on one page — multi-region checks, a decider and an independently hosted page — built around the one property that matters: it works when nothing else does.
- 02
How a journey check works
What a journey check does that a ping does not, the four journeys worth checking, and the rules that stop a monitoring check causing damage of its own.
- 03
How a check becomes an outage
What agreement across three regions means, why two consecutive rounds rather than one, how partial failure is expressed, and the case where the checkers themselves are the problem.
- 04
How the status page stays up
What sharing nothing actually means, the DNS dependency nobody fully escapes, why the page is plain HTML, and how it degrades when even the publisher fails.
- 05
How an incident gets closed
The drafted note a person publishes, the update cadence during an outage, what a resolution has to say, and the monthly figures worth putting on the page.
- 06
What the uptime status poster costs
About $1511 a month. One Bedrock read per check is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.
- 07
Engineering reference: the uptime status poster architecture
Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the schemas and the exact model id.
Frequently asked questions
- What is an uptime status poster?
- A small serverless system that checks customer-facing journeys from several regions, decides when something is genuinely down, and publishes a public status page. The page is hosted independently of the thing it monitors, so it survives the outage it exists to describe.
- Why not just ping the home page?
- Because a home page that returns 200 while checkout is broken is the exact failure a status page needs to catch. Checking the journeys customers use — log in, search, check out — is more work and is the only version that means anything.
- Does it publish automatically?
- It publishes the automated check status automatically. It drafts the human-readable incident and a person publishes that, because the sentence customers read during an outage is a commercial communication, not a monitoring output.
- Why check from several regions?
- Because a single checker cannot tell your outage from its own. Two of three regions disagreeing with the third is a network problem; three of three agreeing is your problem.
- What does it cost to run?
- A couple of dollars a month for a handful of journeys checked every minute. See part six.