Practice incident communication vocabulary: status page update language, investigating/identified/restored phrases, stakeholder notification cadence, and all-clear declaration.
0 / 5 completed
1 / 5
A status page update reads: "We are investigating reports of intermittent errors affecting the payments service. We will provide an update in 30 minutes." What communication principle does this follow?
'We are investigating' is the first phase of incident communication. The key principle: communicate early, even with limited information. Silence breeds anxiety and speculation. The phrase signals: we know about it, we are actively working on it, and we will tell you more in 30 minutes. The update commitment is critical — it tells customers when to stop refreshing the page and prevents support ticket floods from customers who do not know if anyone is aware.
2 / 5
A status page update is changed from 'Investigating' to: "We have identified the root cause — a misconfigured load balancer rule — and are implementing a fix. Service should be restored within 15 minutes." What does this phase of communication signal?
The 'identified root cause' update is a turning point in customer confidence. It answers the most anxious customer question: 'do they even know what's wrong?' The language pattern: state the cause in plain terms (not technical jargon), give a time estimate, and maintain the update cadence commitment. Avoid over-promising on resolution time — 'approximately 15 minutes' with a 30-minute buffer is better than 'fixed in 5 minutes' that slips to an hour.
3 / 5
A status page update reads: "Service has been restored. All systems are operating normally. We are monitoring closely to ensure stability." What purpose does 'monitoring closely' serve in this message?
'Monitoring closely' is standard post-resolution language. It covers a real concern: incidents sometimes recur shortly after mitigation if the fix does not fully address the root cause. Including it in the restoration message: reassures customers the team is still paying attention, sets expectations that a post-mortem will follow, and maintains trust. Follow it with a final update after a suitable monitoring window: 'Stability has been confirmed. Incident closed. Post-mortem to follow.'
4 / 5
An incident manager sets a 'stakeholder notification cadence' of every 30 minutes during a SEV-1. What is a notification cadence?
Notification cadence prevents the communications lead from being reactive — constantly fielding 'any updates?' questions from executives and customers. By pre-committing to a cadence ('update every 30 minutes'), stakeholders know exactly when to expect the next update and stop interrupting the responders. Common cadences by severity: SEV-1 (every 15-30 min internal, every 30-60 min external), SEV-2 (every 30-60 min internal, every 60-120 min external). The cadence is reset when key status changes occur.
5 / 5
An incident commander announces on the bridge: "All-clear — incident is resolved, bridge is closed." What does the all-clear declaration formally signal?
The all-clear is important because incidents can drag on without a clear end. Without a formal close, responders stay on the bridge 'just in case,' wasting energy. The all-clear transitions the incident: response → post-incident. It triggers: closing the status page incident, drafting the internal incident summary, scheduling the post-mortem, and sending the final customer update. Common all-clear language: 'Service is stable. Monitoring period complete. Bridge is closed. Post-mortem in 48 hours.'