A status page is not infrastructure — it is a promise with a timestamp. Four statements: what is broken, what we know, what we are doing, when the next update lands. You do not need a vendor product to keep that promise. You need one static HTML page and the discipline to publish it before the first customer email arrives.
1. The four statements every update carries
- What is broken — in customer terms, not component terms. "Checkouts are failing" beats "payment-worker-3 pool exhausted."
- What we know — including "we are still investigating," said honestly. A known-unknown with a timestamp builds more trust than a confident guess that turns out wrong.
- What we are doing — one line. You don't owe internals; you owe evidence of motion.
- When the next update lands — the line that does the actual work. A page without a next-update time is a press release.
2. Five rows, not forty
Customers can hold about five things in their head. One row per customer-visible capability: Website, App/Dashboard, API, Payments/Checkout, Webhooks. Three states only: Operational / Degraded / Outage. Forty microservice rows is an internal dashboard pointed at customers — and it pushes the one red row below the fold.
3. Update cadence, welded to severity
- P1 (money or data stuck, everything down): first update within 15 minutes of declaring, then every 30 minutes until mitigated, resolution post within 24 hours.
- P2 (degraded, workaround exists): first update within 30 minutes, then hourly.
- The resolution post is mandatory. "Resolved at 14:32 UTC. Root cause: X. What we are changing: Y." An incident that ends silently costs you the trust the page just earned.
4. The template itself
One static HTML file, deployed with your site, zero dependencies:
<h1>Service status</h1>
<p>All systems operational.</p> <!-- the ONLY text on a green day -->
<!-- during an incident: -->
<p><strong>[Degraded] Checkouts are failing for some customers.</strong></p>
<p>Started: 09:12 AEST · We know: card payments fail at 3DS step ·
Doing: payment provider engaged, failing queue paused ·
Next update: by 09:45 AEST.</p>
<p>Workaround: invoices can still be paid by bank transfer.</p>
<!-- resolution: -->
<p><strong>[Resolved] 10:58 AEST</strong> Card payments recovered at 10:41.
Cause: provider-side 3DS timeout. Change: automatic failover to
secondary provider.</p>
During an incident you are editing one file and re-uploading it. The tooling must never be the thing that is down.
5. Wiring it in one afternoon
- Publish the green page before you need it. "All systems operational" live in week one, linked from the footer. A page discovered during an outage and 404ing is the second bad news of the day.
- Give the on-call edit rights. No approval loop, no comms-team gate. If updating the page requires a meeting, the page will lie by omission.
- Drill the edit once. Next game day: the on-call posts a fake degraded update end-to-end.
- Link it everywhere customers already look — footer, app settings, support macros. During an incident, replies open with the page link.
6. The traps
- The silence gap. The first 30 minutes decide whether customers think you're honest or hiding. An "we are investigating" update at minute 12 prevents a hundred "is it just me?" tickets.
- The green page during a live incident. A page that says "all operational" while support is on fire converts a technical failure into a credibility failure. If you can't update fast, put "aware of an issue, updates every 30 min" in the header and buy the cadence honestly.
- Marketing copy in incident updates. Short, factual, timestamped. Nobody in a burning building wants the fire's journey.
- One-timezone timestamps. Relative times plus absolute timestamps in UTC and local.
- Forty-component theater. Five rows, red on top.
A worked example
A fourteen-person invoicing SaaS had no status page. A payment-provider incident: team knew in four minutes, fixed in fifty, stayed silent — "no news means we're on it." Result: 61 support tickets, three enterprise escalations, one churn citing "we couldn't tell if you even knew."
Afterwards they shipped a five-row static page. Next similar incident: first update at minute 8, updates at +30/+60/+90, resolution post. Nine tickets, zero executive escalations — and the customer who had churned renewed. Same engineering effort both times. Only the storytelling changed.
Metrics worth tracking
- Time-to-first-update: <15 min P1, measured from incident declaration — not from when someone remembered.
- Update-cadence adherence: 100% of promised next-update times met.
- Support tickets per incident: trending down as the page matures.
- Silent minutes during a declared P1: zero after the first update.
The full template page (copy-paste HTML, severity cadence table, drill checklist) is free on HIVE80lab Ops Notes.
If you want the surrounding kit — incident response plan, severity matrix, ransomware playbook for a 1–50 person team — the Ops Starter Kit covers it, and The First 30 Minutes is a free incident quick-start checklist.
Top comments (0)