Writing Customer-Facing Status Page Updates
Status states, update format, empathy language, resolution messages, and update cadence
Status page update essentials
- Status states: Investigating → Identified → Monitoring → Resolved — each signals a distinct phase
- Update format: status label + specific symptom + affected scope + next update time
- Empathy: name the actual impact ("not being able to complete a purchase") — not "any inconvenience"
- Resolution message: resolved time + service confirmed + impact summary + post-mortem commitment
- P1 cadence: every 15–30 minutes + immediately on status change + "no change" if no new info
Question 0 of 5
What are the four standard status page states used during an incident lifecycle, and what does each mean?
Investigating → Identified → Monitoring → Resolved — each signals a distinct phase. Status page state meanings:
- Investigating: "We are aware of reports of X and are actively investigating" — you know there's a problem, not yet the cause
- Identified: "We have identified the cause and are working on a fix" — root cause known, fix in progress
- Monitoring: "A fix has been deployed. We are monitoring to confirm stability" — the fix is live but not yet verified as stable
- Resolved: "This incident has been resolved. Service is operating normally." — the incident is closed
- Moving directly from Identified to Resolved without a Monitoring phase often leads to premature resolution declarations
- Monitoring tells customers: "we think it's fixed but we're not yet certain" — honest and keeps trust intact
- Monitoring also gives the team a window to catch regressions before fully closing the incident
Which customer-facing status page update is written most effectively?
Status label + specific symptom + affected scope + next update time. Customer status update formula:
- Status label: "Investigating" — tells customers where in the incident lifecycle you are
- Specific symptom: "slow checkout page load times" — matches what customers are experiencing; validates their frustration
- Scope: "affecting a portion of customers" — honest about scope without false precision
- Observable condition: "load times above 5 seconds" — concrete, not vague
- Next update time: "by 15:30 UTC" — removes the need for customers to refresh repeatedly
Which empathy statement for a status page update is most effective?
Specific empathy: name the actual impact + acknowledge the person's experience + genuine apology. Empathy statement quality levels:
- ❌ "any inconvenience" — minimises the impact; "inconvenience" is what happens when a form is too long, not when purchases fail
- ❌ "we know this is frustrating" — generic; doesn't show you understand what specifically is frustrating
- ✅ "not being able to complete a purchase during this period" — names the actual experience customers had
- ✅ "has affected many of you" — acknowledges scale without false precision
- ✅ "we're sorry for the disruption" — direct, no hedging ("any inconvenience this may have caused" implies it might not have)
A service has been resolved. Which resolution message is written most completely?
Resolution message: resolved time + service restored confirmation + impact summary + post-mortem commitment. Resolution message formula:
- Resolved time: "17:42 UTC" — clear end of incident; enables customers to reconcile their own records
- Service restored confirmation: "Checkout service is operating normally" — specific service, not vague "everything is fine"
- Impact summary: "23% of users between 14:35 and 17:42 UTC (3h 7m)" — acknowledges the full scope for customers assessing their business impact
- Post-mortem commitment: "within 48 hours at [link]" — signals accountability and provides a place customers can follow up
What is the correct update cadence for a customer-facing status page during a P1 production incident?
P1: every 15–30 minutes + immediately on status change + brief "no change" if no new info. Update cadence rationale:
- Every 5 minutes creates noise and forces customers to read every update to check if anything changed — exhausting and trust-eroding
- Only on resolution leaves customers in the dark — they stop trusting your status page and contact support instead, creating more work
- Every 15–30 minutes is frequent enough that customers know the team is actively working; infrequent enough that each update has substance
- "15:30 UTC — No change since our last update. Our team continues to investigate. Next update: 16:00 UTC." — confirms the team is still on it even when there's nothing new to report