Status Page Template: What to Tell Customers During an Outage (Before They Ask)

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.” Name the symptom the customer can see.
• 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. “Engineering has identified the failing job and is pausing it.” You do not 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; the timestamp is what lets customers stop refreshing and go back to their day.

2. The component model: five rows, not forty

Your status page is for customers, and customers can hold about five things in their head. One row per customer-visible capability — for a typical SaaS: Website, App / Dashboard, API, Payments / Checkout, Webhooks. Every row has three states only: Operational, Degraded, Outage. If your page has forty microservice rows, you have built an internal dashboard and pointed customers at it. The five-row version also forces the only question that matters at 3am: which rows are lying?

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, then a 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 whole page just earned.

The cadence belongs in the severity matrix, not in someone’s memory — the severity row already defines who is told and how often; the status page is just the channel that keeps that promise in public.

4. The template itself

One static HTML file, deployed with your site, zero dependencies. Copy, edit the rows, ship:

<h1>Service status</h1>
<p>All systems operational.</p>   <!-- the ONLY text on a green day -->

<!-- during an incident, replace with: -->
<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. Full write-up linked in the incident report.</p>

Three states, four statements, one page. 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 by customers during an outage is found by the URL they guess, and if it 404s, you have told them the second bad news of the day.
• Give the on-call the edit rights. The incident commander or on-call edits the page directly — 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. First drill fails, embarrassingly and usefully — usually at “where do I even upload this.”
• Link it everywhere customers already look. Footer, app settings, support macros. During an incident, your support replies should open with the page link so the clock of “when is the next update” runs on their screen, not in your inbox.

6. The traps

• The silence gap. The first 30 minutes of an incident are when customers decide whether you are honest or hiding. An update that only says “we are investigating” posted at minute 12 prevents a hundred “is it just me?” tickets — the void is always filled by speculation, and speculation is always worse than the truth.
• The green page during a live incident. A status page that still says “all operational” while Twitter (and your support queue) is on fire converts a technical failure into a credibility failure. If you cannot update fast, update the header to “We are aware of an issue and are working on it — updates every 30 min” and buy yourself the cadence honestly.
• Marketing copy in incident updates. “We are experiencing some minor inconvenience while our team passionately innovates” — customers in a burning building do not want to hear about the fire’s journey. Short, factual, timestamped.
• Timestamps in one timezone only — yours. Customers are not all in your timezone. Relative times (“next update within 30 minutes”) plus absolute timestamps in UTC and local is the honest combination.
• Forty-component honesty theater. Detailed pages feel rigorous but push the one red row below the fold. Five rows, red on top.

7. Worked example: a fourteen-person invoicing SaaS

A fourteen-person invoicing SaaS had no status page. Their payment provider had a 3DS timeout epidemic one Tuesday; the team knew within four minutes, fixed the routing in fifty, and stayed completely silent the whole time — “no news means we’re on it.” Meanwhile: 61 support tickets, three enterprise customers escalated to their account managers, and one churned citing “we couldn’t tell if you even knew.” The status page they shipped afterwards was one static HTML file with five rows. Three months later, a similar provider incident: first “aware & investigating” update at minute 8, updates at +30/+60/+90, resolution post with cause and failover change. Nine tickets total, zero executive escalations, and the enterprise customer who churned sent a note praising the comms — then renewed. The outage cost the same engineering effort both times. Only the storytelling changed.

8. Metrics

• Time-to-first-update: <15 min for P1, <30 min for P2, measured from incident declaration — not from when someone remembered.
• Update cadence adherence: 100% of promised next-update times met, including the awkward “still investigating, next update at 10:15” ones. A missed promised update costs more trust than the incident itself.
• Support tickets per incident: trend down as the page matures; a spike means the page was late, wrong, or undiscoverable.
• Silent minutes: minutes during a declared P1 with no public update. Target: zero after the first update.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start
• Ops Starter Kit — incident response for small teams — $14
• Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
• Ops Mega Bundle — all 5 kits in one download — $49

Related: the outage email templates carry the same four statements into every affected customer’s inbox, the database outage runbook is what the on-call is doing while the page updates, and the severity matrix sets the update cadence the page must keep. The incident response pillars overview shows where public comms sits among the four pillars.

Release notes are the planned side of the same honesty the status page template keeps on the unplanned side: what changed, what is broken, what we are doing, when to look again — customers should never have to guess which one applies.

The five components on the public page are rows on an internal page. The service catalog template defines those rows — service, owner, and the one-sentence “up means” the status page template publishes when the promise breaks.