Writing the All-Clear Resolution Message in Incident Comms

Option B is correct. An all-clear message opening should contain: (1) RESOLVED label — uppercase, scannable in busy channels; (2) resolution timestamp in UTC — unambiguous, time-zone-safe; (3) incident reference — INC number links to the incident ticket; (4) explicit service name — "payment service degradation", not "the issue"; (5) current status — "all systems operating normally." This format lets people who missed the incident scan and understand in one sentence. Option A is tentative ("I think", "probably"). Option C is informal and lacks the timestamp and reference. Option D lacks the timestamp and is imprecise.

Option C is correct. A resolution description should include: (1) the specific root cause (misconfigured nginx timeout, exact value), (2) what was done to fix it (timeout increased to 120s, connections flushed), (3) when the fix was applied (14:39 UTC), and (4) a measurable confirmation of recovery (error rate below 0.1% by 14:44). This gives stakeholders confidence that the fix is real and complete — not just that someone clicked a button. Options A, B, and D are vague. "The problem was fixed" without details leaves stakeholders wondering whether the same incident could recur. Specificity in the resolution description is what builds trust.

Customer impact summary is the essential next section. After stating what happened and how it was fixed, stakeholders (customers, leadership, partner teams) need to understand: who was affected (which services, users, regions), for how long (start to end time), and to what degree (total outage or degraded performance, percentage of requests failed). Example: "Impact: 23% of payment API requests returned HTTP 502 between 13:55 UTC and 14:44 UTC (49 minutes). Approximately 8,400 failed transactions were affected. Retries succeeded for 72% of these within 30 seconds." This enables downstream teams to assess their own impact and communicate to their users. Apologising (option A) may be appropriate but is not the highest-priority next section.

Option B provides three concrete, timestamped, trackable next steps: a scheduled post-mortem with a date and channel, the incident ticket status, and an immediate preventive measure. Good next-steps sections in all-clear messages: (1) commit to a specific follow-up (post-mortem date and time), (2) state the incident ticket status (open/closed), and (3) describe any interim mitigations while the root cause is fully addressed. Option A ("we will make sure this doesn't happen again") is an empty promise. Option C is vague. Option D is reactive and puts the burden on the reader. All-clear messages should close the communication loop with concrete, dated commitments.

Option C demonstrates the correct tone: calm, professional, factual, and accountable. It acknowledges the impact ("disruption to your workflows"), takes organisational responsibility without assigning individual blame, and commits to a follow-up deliverable (post-mortem by a specific date). The tone of all-clear messages reflects the maturity of the engineering team. Option A is emotional and unprofessional ("nightmare", "finally"). Option B is blame-focused — even if accurate, this is not appropriate in a stakeholder-facing communication. Option D is uncertain and undermines confidence ("not sure what happened"). All-clear messages should close the incident communication with confidence, accountability, and forward-looking clarity.