5 exercises on incident response key phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
Your monitoring alerts and you join the incident channel. What do you say to open the incident formally?
DECLARING AN INCIDENT: Use the structured declaration format — severity, affected service, impact, and immediately claim the Incident Commander (IC) role. "Declaring SEV-2 incident. Service: payment-api. Impact: checkout failures. I'm taking IC." creates instant clarity. Examples: "Declaring SEV-1. Service: auth. Impact: all logins failing. IC: me. Comms lead: Priya." / "Declaring SEV-3. Downstream latency on orders-api. IC: James." / "SEV-2 declared. DB primary unreachable. I'm IC, Sarah — can you take comms?" Options A/B/D are vague, passive, and waste precious seconds at incident start.
2 / 5
As IC you need to assign a communications lead. Which phrasing is clearest?
ASSIGNING ROLES DIRECTLY: In an incident, role assignments must be direct, named, and include explicit responsibilities. "Marco, you're comms lead — keep the stakeholder channel updated every 15 minutes." eliminates ambiguity. Examples: "Priya, you're comms lead. Post updates every 10 minutes to #incident-comms." / "James, take comms. Keep the business channel informed and field executive questions." / "You're comms lead — your job is stakeholder updates and keeping noise out of the war room." Options B/C/D are indirect or lack named ownership, which causes role confusion mid-incident.
3 / 5
The team asks for a status update 10 minutes in. What is the most professional update format?
STATUS UPDATE FORMAT: The professional standard is "Current status: [state]. Working theory: [hypothesis]. Next update in [time]." This phrase pattern — used at Google, PagerDuty, and most SRE teams — gives stakeholders a clear state, a hypothesis, and a time to expect more. Examples: "Current status: mitigating. We've identified the root cause as a misconfigured deployment. Next update in 5 minutes." / "Current status: monitoring. Rollback complete. Watching error rates." / "Current status: investigating. No working theory yet. Next update in 10 minutes." Vague updates (A/B/C) erode trust and generate interruptions.
4 / 5
You've found the fix and are about to apply it. How do you communicate this?
MITIGATION LANGUAGE: Announce mitigations with what you're doing, why, and what to watch. "Applying mitigation: rolling back to v2.3.1. Expected resolution: 5 minutes. Watch error rates." gives the team and stakeholders a shared picture. Examples: "Applying mitigation: reverting the feature flag. Watch latency on the orders dashboard." / "Mitigation: restarting connection pool. Impact: ~30s of additional latency expected." / "Applying fix: scaling up RDS read replicas. Monitor DB CPU and query times." Options A/C/D are unprofessional and provide no useful information for the team to act on.
5 / 5
The incident is resolved. What is the correct all-clear phrase?
ALL-CLEAR PHRASE: The formal close includes resolution time, a monitoring window, and next steps. "Incident resolved. Service restored at 14:32 UTC. Monitoring for 30 minutes before closing. Post-mortem scheduled for Thursday." follows industry SRE practice. Examples: "Incident closed. Error rates nominal since 09:15 UTC. Post-mortem owner: Ana. Doc link: [url]" / "SEV-2 resolved. Service healthy. We'll monitor for 1 hour. Post-mortem in 48 hours." / "Declaring all-clear. Payment-api fully restored. Closing incident at 16:00 UTC." Options A/B/D are casual and skip the monitoring window and follow-up, which are critical for true resolution confidence.