After a major outage, how do you run a postmortem so people are honest, and how do you make sure the action items actually get done?

What the interviewer is looking for

• This question tests incident response. Describes a clear sequence of triage, mitigation before root cause, role assignment, communication and blameless postmortems with tracked actions.
• Strong answers: Blameless framing, timeline from data, focus on systemic causes, a small set of owned and prioritised actions, and follow-up tracking with leadership support.
• Likely follow-up: What do you do when the same type of incident keeps recurring?

Another way it may be asked: A big outage just happened. How do you review it without blame and make sure the fixes really happen?

A structure to follow: Answer, explain, example, limits

1. Step 1

   Answer

   Give your direct answer in the first sentence so the interviewer knows where you are going.

2. Step 2

   Explain

   Say how it works or why you would do it that way, in plain words before jargon.

3. Step 3

   Example

   Anchor it in something you have actually done or seen, with the detail that shows hands-on experience.

4. Step 4

   Limits

   Say when your approach would not be the right one. It shows judgement.

This is guidance on shape, not a script. Use your own real experience and facts; never invent details to fill a gap. See the STAR guide and answer frameworks.

Common slips

• Reciting a definition without showing you have applied it.
• Using terms you cannot explain if asked a level deeper.
• Claiming experience beyond what you can discuss in detail.

How to practise it

Say the answer in 90 seconds, then answer the follow-up as if it were a new question.

Related questions

• You are on call, and at two in the morning you get paged that the checkout page is returning errors. What do you do in the first ten minutes?
• What is the difference between a service level indicator, a service level objective and a service level agreement, and why would a team care about the difference?
• A Linux server is suddenly very slow. What are the first things you would check, and what would each one tell you?
• How do you decide what deserves to page a human at night versus what can wait for a ticket in the morning?
• Your service has burned most of its error budget halfway through the month. What happens next, and how do you talk to the product team about it?

Browse all questions