Prompt and scope
This is a behavioral question about judgment and collaboration, not a request to retell outage details. Explain how pre-agreed triggers help evaluate user impact, response quality, recurrence risk, and learning value, then turn the decision into a useful, blameless review. Google SRE recommends postmortems for significant undesirable events; common triggers include user-visible degradation, data loss, rollback intervention, resolution beyond a threshold, and monitoring failure. Any stakeholder may also request one.
What the interviewer evaluates
- Whether you translate “small impact” into observable metrics and explicit thresholds.
- Whether you separate containment from learning and avoid treating a postmortem as blame or a writing contest.
- Whether you can propose lightweight and full scopes instead of a binary choice.
- Whether actions have owners, dates, and verification evidence.
- Whether you communicate respectfully and make the learning valuable to related teams.
Clarifying questions to ask
- What fraction of requests, users, SLO error budget, and business value were affected during the 18 minutes?
- Did the event require rollback, manual intervention, missed monitoring, or repeat a similar failure?
- Does the team already have postmortem criteria, severity levels, and action tracking?
- Who needs the result, and are privacy, compliance, or external communication involved?
- Is a full report needed, or can a short review answer the important questions?
A 30-second answer
“I would not decide from ‘only 18 minutes.’ I would apply the pre-agreed criteria for impact ratio, user visibility, error budget, rollback intervention, monitoring quality, and recurrence risk. Because users saw failures and a rollback occurred, I would at least run a short, blameless review with a timeline, impact, response, and two or three high-value actions; evidence can expand it into a full report. Every action needs an owner, due date, and verification signal, then belongs in the team backlog or on-call process until closed.”
Step-by-step deep dive
Step 1: Apply a trigger standard
Place the event in the existing severity model: user impact, duration, error-budget consumption, data integrity, manual rollback, monitoring failure, and cross-team response. Define thresholds before incidents so they are not changed for a particular team afterward. Eighteen minutes is not a conclusion; partial failure plus rollback already meets many teams' lightweight trigger.
Step 2: Choose review depth
A full postmortem includes a timeline, impact assessment, root and contributing causes, response effectiveness, and preventive actions. If impact is small and one cause is well understood, start with a time-boxed 30-minute review to test recurrence risk, then expand only when evidence requires it. Lightweight means fewer participants, pages, and actions, not missing facts.
Step 3: Stay blameless and evidence-led
Assume people made reasonable choices with the information available and ask how the system made failure easier: release safeguards, alerts, permissions, runbooks, or missing context. Avoid conclusions such as “someone forgot to check” that cannot change the system. Cite logs, change records, and communication history, and label unknowns instead of filling them with guesses.
Step 4: Make actions executable
Write an owner, due date, priority, dependency, and completion evidence for each action. Examples include a pre-release health check, a rollback drill, or a corrected alert threshold. “Be more careful” and “add testing” are not acceptance criteria. Put actions in the backlog and review them against an agreed SLO; Google SRE notes that a postmortem without follow-up action does not improve reliability.
Step 5: Resolve stakeholder disagreement
Explain the review cost and recurrence-prevention value to the product manager, and explain the impact boundary to the engineer asking for a long report. Offer a time-box: publish one page of facts and actions first, then expand when evidence warrants it. If any stakeholder believes the event deserves review, record the reason and include it in the assessment rather than letting hierarchy veto it.
Step 6: Verify closure and sharing boundaries
After publication, check action status, repeated alerts, similar releases, and error-budget trends. Remove user identifiers and sensitive details for the audience while sharing conclusions with teams that can benefit. A review should not become public shaming, but excessive access restrictions also make repeated failure likely. Keep the evidence and final version for later audit and learning.
High-quality sample answer
“I would apply the severity and postmortem triggers defined before the incident instead of deciding from 18 minutes. User-visible failures and rollback intervention justify at least a time-boxed, blameless review covering impact, timeline, response, and recurrence risk. I would cite logs and change records, separate root from contributing causes, and expand to a full report only if monitoring, release safeguards, or runbooks reveal a systemic gap. Each action gets an owner, due date, priority, and verification signal in the backlog. I would explain cost and recurrence value to the product manager, keep scope controlled for the engineer requesting a long report, and share a redacted result with teams that benefit. Closure requires evidence that actions finished and similar incidents declined.”
Common mistakes
- Using duration alone while ignoring user ratio, error budget, rollback, and monitoring failure.
- Turning the postmortem into a blame investigation that makes on-call staff hide information.
- Listing dozens of actions for completeness without owners or completion evidence.
- Replacing acceptance criteria with “test more” or “be more careful.”
- Canceling the review because one product stakeholder says it is unnecessary.
- Writing the document without tracking actions or checking whether similar incidents decline.
Follow-up questions and answers
What if the team has no common postmortem standard?
State the current evidence: user impact, error budget, rollback, monitoring, and recurrence risk. Use this incident to propose a minimal trigger checklist and agree on the next version with the team. Do not invent a complex policy during the incident.
What if the review finds that one person made a clear mistake?
Record the information and system constraints behind the decision, then ask how process, tools, or training can reduce recurrence. Intentional policy violations or safety issues can follow a separate management process; keep the postmortem blameless so its learning purpose remains clear.
How do you prove a short review was sufficient?
It must answer impact, timeline, response, root-cause hypothesis, and actions, then check action evidence and similar metrics at the agreed time. Unknown impact, cross-team dependencies, or recurrence risk should expand the scope; short length alone is not completion.