When the Green Banner Lies: Rehearsing Incident Comms Against What Customers Actually See
Photo: Programs & Events Dashboard, Public domain, via Wikimedia Commons
A status page is a promise rendered in HTML. At 09:12 on a Tuesday it can read 'All systems operational' while a customer in Leeds refreshes a failed login for the fourth time and a basket in Manchester will not recalculate. The outage is the smaller problem. The contradiction is what gets remembered, and it is what the next quarterly review will quote back at you.
UK digital teams have become genuinely good at detection: synthetic journeys through checkout, real-user monitoring on the product page, edge logs that surface a 502 before the contact centre does. What receives far less rehearsal is the final mile — the two sentences published under pressure, which either stand up against the evidence or quietly spend down the confidence the rest of the stack has earned.
A Status Page Is a Claim, Not a Mood
Treat every public line as a hypothesis about the customer experience. 'Operational' is not a feeling in the incident channel; it is an assertion that can be checked against synthetic results and real-user data for the same minute. When the three disagree, the status page is not the arbiter. It is the accused.
The useful question shifts from 'did we communicate?' to 'did our communication match what a customer could observe?' That reframing turns incident comms into something testable, which is the only condition under which it improves.
The Three-Signal Rehearsal
Book two hours a quarter, and one additional session in the fortnight before peak trading. Choose a genuine incident from the last ninety days, or inject a controlled one on a journey you can afford to fail: search, or a secondary payment method.
Then reconstruct three streams on matching timestamps:
- The public timeline. Every status update, in-app banner and social post, with the minute it went live. Screenshot it, because status pages are edited retrospectively more often than anyone admits.
- Synthetic truth. Per-step journey checks — home, search, product, basket, sign-in, payment — at one-minute resolution, tagged by region.
- Real-user evidence. RUM error rates, sign-in failure ratios and checkout completion, segmented by device and region. A London fibre connection is not a rural 4G connection, and the page cannot tell the difference.
Lay all three on one axis and ask a single question of each interval: what did we say, and what did the customer see? The gaps are the finding. Teams are consistently surprised by how often the page said 'investigating' for twelve minutes after synthetic checks had recovered, and by how often it said 'operational' while a regional peering path was failing.
A Scorecard for Trust Consistency
Score each dimension from 0 to 3 and circulate the result internally, whatever it says.
| Dimension | What is tested | Score 0 looks like | Score 3 looks like |
|---|---|---|---|
| Signal alignment | Does each status line match synthetic and RUM evidence for the same minute? | Green page during a 40% sign-in failure rate | Status text changes within one update cycle of the first signal |
| Scope honesty | Are affected journeys named, or hidden behind 'some users'? | 'Intermittent issues affecting some customers' | 'Card payments failing; PayPal and gift cards unaffected' |
| Cadence discipline | Were promised update times kept? | Two commitments missed | Every promised timestamp met, even with nothing new to say |
| Symptom language | Customer words rather than internal jargon | 'Elevated 5xx on the auth cluster' | 'Customers cannot sign in' |
| Correction quality | Did the page correct its own earlier optimism? | Silent edits | Timestamped correction naming exactly what changed |
A composite score across four rehearsals matters less than the trend. A team that climbs from 6 to 11 over a year has demonstrated something a press release cannot.
P1 Wording That Survives Contact With Evidence
Four rules do most of the work. Name the journey, not the system. State what still works. Give a timestamp and keep it. Never estimate a fix you cannot defend.
Investigating — 09:12. Customers using card payment may see an error at checkout. Browsing, search and PayPal checkout are working normally. We are investigating and will update by 09:42.
Update — 09:42. Card payments are still failing for most customers. We have identified the cause in our payment provider integration. There is no fix yet. Next update by 10:12.
The second message is uncomfortable and correct. 'No fix yet' delivered on time buys more credibility than vague reassurance delivered late, and it also protects the engineer who would otherwise be improvising a timeline in public.
Cadence Is Part of the Message
Decide the rhythm before the incident, not during it: a first public update within fifteen minutes of a confirmed P1, then every thirty minutes until mitigated, then hourly through recovery. Assign the writing to a named role and have a second person check it against the dashboards before publication.
A missed update is read as a larger failure than the outage itself, because it suggests nobody is watching. That perception is expensive and entirely avoidable.
The Update Nobody Writes
Corrections are the most neglected part of incident comms. If the page was wrong, say so on the page, with a timestamp, and describe the change you have made.
Post-incident correction — 14 November 2026. Between 09:04 and 09:38 this page showed 'operational' while customers could not complete card payments. Our monitoring detected the failure at 09:06. Our public message was incorrect for 34 minutes. We have added a synthetic card-payment check to the on-call alert path and removed manual approval for status updates during a P1.
Do not rewrite history by editing old entries. Append, timestamp and link. A visible correction trail is a trust asset; a sanitised one is a liability the moment anyone has a screenshot.
Make the Page Part of the Product
Own the status page in engineering, review its wording like code, and test it like a customer journey. The objective is not a prettier page. It is evidence. When a partner, a regulator or a frustrated customer asks what you knew and when, a minute-by-minute trace is a far better answer than a paragraph of apology.
