Quick answer: Customers do not distrust status pages because incidents happen; they distrust them because updates are vague, late, and quietly deleted. An update earns trust when it carries five facts — what is broken, who is affected, what you are doing, when the reader hears from you next, and what they can do meanwhile — posted on a cadence you promised and closed with a plain-language resolution note. Below is the copy-paste template we hold our own updates to at status.orbit.devotel.io, the cadence rules behind it, and the pre-publish checklist to run before an update ships.
1. Why most status page updates erode trust
Four patterns cause most of the damage, and none of them is a writing-talent problem.
Vague scope. "Some users may experience issues" forces every reader to run their own diagnosis to find out whether they are affected. A reader who cannot tell assumes they are. A reader who checks and finds out they are not still does not trust the next update, because the next update might be about them and say the same nothing.
Silence between updates. When no update names the time of the next one, forty quiet minutes read as forty minutes in which nobody worked the problem. The team may have been in a war room the entire time; the page shows a void.
Premature resolution. Marking an incident resolved before retries drain, caches expire, and the last webhook redelivery lands produces a second wave. The second incident post on the same day cancels the credibility of the first.
No actor. "It has been determined that..." tells the reader nothing about who is working the problem or what they committed to. Passive voice on a status page reads like a press office, not an engineering team.
All four are structure failures, and the fix is structural: a template that makes the five facts mandatory, a cadence that makes silence impossible, and a checklist that catches the failures before publish.
2. The five facts every update carries
- What is broken, in the customer's words. Name the symptom the customer sees: "webhook deliveries to your endpoints are delayed 10-15 minutes", not "an internal queuing issue". If the reader cannot match the sentence to their own dashboard, the sentence is not finished.
- Who is affected, as narrow as you know. Feature, region, carrier, plan tier. "SMS to Vodafone UK numbers" beats "some messaging traffic". If scope is still unconfirmed, say so and name when you expect to confirm it; "unknown, by 14:30" beats a guess.
- What you are doing now. One sentence, active voice. "We are rerouting US-East SMS traffic to backup routes" says more than "the issue is being looked at". You do not owe the reader your internals; you owe them evidence of an actor.
- When the reader hears from you next. A concrete time, not "as soon as possible". This is the fact that turns silence from concealment into schedule.
- What the reader can do meanwhile. A workaround, or the sentence "there is no workaround right now". An explicit no-workaround line is information; its absence is a trap the reader finds at 2 a.m.
Any update that omits one of the five leaves the reader to fill the gap, and readers fill gaps with the worst case.
3. The template: first update, follow-up, resolution
Three documents cover an incident's whole life. Placeholders sit in angle brackets; every line is mandatory, including the ones that say "unknown".
FIRST UPDATE - post within 15 minutes of confirming an incident
<One-line symptom in the customer's words>
Status: Investigating
Started: <HH:MM UTC>
What's happening: <the symptom the customer sees, with the error or delay they observe>
Who's affected: <feature, region, carrier, or plan tier; "scope being confirmed, expect it by <HH:MM>" if unknown>
What we're doing: <one sentence, active voice, the current action>
Workaround: <the workaround, or "No workaround right now. This line updates when that changes.">
Next update by: <HH:MM UTC, at most 60 minutes out>FOLLOW-UP - post at every promised time, including when nothing changed
Status: <Investigating | Identified | Monitoring>
Change since last update: <what moved: scope narrowed, fix deploying, delivery rate recovering>
What we're doing: <the current action>
Workaround: <unchanged, or the new workaround>
Next update by: <HH:MM UTC>"Change since last update: none yet, investigation continuing" is a real update. It resets the reader's worst-case clock. It is also the update a team under pressure is most tempted to skip, which is exactly why it is the one that builds trust.
RESOLUTION - post within 60 minutes of recovery, before cache drain looks like a second incident
Status: Resolved
Resolved at: <HH:MM UTC>
What happened: <the failure in the customer's words, not the internal service name>
Root cause: <plain language: the thing that broke, and the thing that should have caught it>
What we're changing: <specific follow-ups you commit to: an alert threshold, a deploy gate, headroom with a date>
Postmortem: <the date it will publish, or "we will link it here when published">The resolution note is the document your reader screenshots and forwards. Write it for the person who has to decide whether to renew with you.
4. Cadence rules that keep silence from reading as concealment
- Acknowledge within 15 minutes of confirmation. The first update needs no cause; it needs the five facts with "unknown" where the cause goes.
- Commit to an interval and keep it. Thirty minutes for customer-affecting outages, sixty for degraded service. The interval is a promise, and a broken promise costs more than bad news.
- Post on schedule even when nothing changed. The "no change" follow-up is the cheapest trust you will ever buy.
- One source of truth. The status page leads; email, in-product banners, and social posts link to it. Three surfaces drifting out of sync reads as three teams not talking.
- Resolve late, not early. Mark resolved when recovery is visible from the customer's seat: retries drained, caches expired, receipts green for two update intervals in a row.
5. The resolution update is where trust is won
Readers forgive incidents; they remember endings. A resolution note that names the root cause in plain language and commits to specific changes turns an outage into evidence that your engineering team tells the truth. A note that says "the issue has been resolved, thank you for your patience" turns it into marketing.
Two rules for endings. First, root cause in the customer's words: "a configuration change removed a retry limit on our SMS queue" is honest and safe; the internal postmortem with stack traces lives elsewhere. Second, commit to changes someone can check: an alert threshold, a deploy gate, capacity headroom with a date on it. If you publish postmortems, give the date this one lands and link it from the same page.
For communication-platform operators, the kill-switch question belongs to the same discipline: knowing which incidents you update through and which ones you halt outbound traffic for is part of incident communication. We wrote the operator side of that in Emergency Stop: The Org-Wide Kill Switch for Outbound Traffic, and the paging side in the on-call escalation API explainer.
6. The pre-publish checklist
Run this before every update, including the "no change" ones.
- [ ] Scope sentence names the feature, region, or carrier in the customer's words, no internal service names
- [ ] Workaround line is present, including when it says "no workaround"
- [ ] Next-update time is present, realistic, and on a clock the on-call rotation actually watches
- [ ] Status word is one of the page's defined set: Investigating, Identified, Monitoring, Resolved
- [ ] No internal artifacts: no incident-channel names, ticket ids, runbook ids, or provider account references
- [ ] Times carry their timezone, UTC on public pages
- [ ] The update is mirrored to the surfaces that link to the page (in-product banner, email, social) rather than duplicated with different wording
- [ ] One named owner approved it: the incident commander, not a committee
Frequently asked questions
How fast should the first update go up?
Within 15 minutes of confirming an incident exists. Confirmation, not cause: an update that says "SMS delivery to Vodafone UK is failing, scope being confirmed, next update by 14:30 UTC" is complete at minute 15 even when the cause is still unknown at minute 60.
Should we post when nothing changed?
Yes, at every promised time. The follow-up template's "Change since last update: none yet" line exists for exactly this. Skipping it is the fastest way to turn a schedule into a void.
What belongs on the status page versus a customer email?
The status page is the single source of truth; emails and in-product notices link to it. Email a segment directly only when their situation is theirs alone, for example an enterprise customer on the affected route with a contractual SLA, and even then the email links to the page for the timeline.
Do we publish root causes during an active incident?
Publish what is safe and useful to the reader: scope, impact, action, workaround. Hold the full root cause for the resolution note, where you can state it once, correctly, with the changes that follow it. A guessed cause at minute 20 that gets retracted at 50 costs more trust than an honest "unknown".