5 exercises — writing SEV-level notifications, impact statements, blameless root cause analysis, and time-bound action items.
0 / 5 completed
Incident report checklist
Notification: SEV level · system · impact scope · start time (UTC)
Impact statement: who is affected, who is NOT affected
Root cause: name the process/system failure — not the person
Action items: specific action · individual owner · deadline
Tense: present for ongoing, past simple for resolved events
1 / 5
A production service has gone down. You need to send an initial incident notification. Which opening sentence is most effective?
Incident notifications must lead with severity, system, impact, and start time — the four facts stakeholders need first. Use the format: SEV-[N] | [System] [Status] | Impact: [user/business scope] | Since: [time UTC]. Option A is vague ("some kind of issue"). Option C sounds apologetic rather than informative. Option D starts with a probable cause before confirming the impact — cause analysis belongs in a later update, not the first notification.
2 / 5
Complete the impact statement in this incident report: "Users _____ (affect) by this incident are those attempting checkout with a saved payment method. Orders using PayPal _____ (not/affect)."
Use present simple passive to describe the current state of the incident: "Users are affected" (right now, ongoing). This is more direct and natural than the participial phrase "users being affected" or the relative clause "users that are affected". The negative, "are not affected", clearly scopes the impact — limiting scope is a key part of professional incident communication (it reduces panic and helps triage).
3 / 5
You are writing the root cause section of a post-mortem. Which wording follows blameless post-mortem principles?
Blameless post-mortems describe system and process failures, not individual ones. Option C is correct: it names the technical artefact (misconfigured environment variable), the action (deployed to production), and the process gap (bypassing environment validation in CI). Option A names an individual — this violates blameless principles and discourages psychological safety. Option B still uses "developer error" (blame). Option D is informal and lacks precision.
4 / 5
You're writing action items at the end of a post-mortem. Which action item is written correctly?
Post-mortem action items must be specific, measurable, assignable, and time-bound. Option C is the only one that meets all four criteria: it specifies the exact technical action (alerting on connection pool exhaustion, threshold >80%), names an owner (@alice), and has a deadline (2024-02-15). Options A and D use vague language ("probably", "more checks across the board"). Option B lacks a deadline and an individual owner — "backend team" is not an owner.
5 / 5
Choose the best phrase to complete a resolution update: "The incident _____ at 15:47 UTC after we _____ the connection pool limit and _____ the affected instances."
Past simple passive (was resolved) is standard for incident resolution announcements — the incident is a specific completed event. The subsequent actions (increased the connection pool limit, restarted the affected instances) are also past simple — a completed sequence of actions in the past. Present perfect ("has been resolved") would work in a real-time update ("we're happy to report…"), but past simple is cleaner for formal post-mortem writing. The "did + base verb" construction (Option D) is emphatic and sounds unnatural here.