DevOps Engineer interview question
How do you triage a service incident?
Establish impact and severity, assign command and communications, check recent changes and core service signals, mitigate the largest user harm first, preserve evidence, and record a timeline before deep root-cause work.
Direct answer
What a strong answer covers
How it works
Triage is about deciding fast with incomplete information. First establish what users are experiencing and how many, which sets severity and who must be woken. Assign an incident commander who coordinates and a communications lead who updates stakeholders on a fixed cadence, so responders can work. Check the obvious accelerants: recent deploys, config changes, traffic anomalies, and dependency status pages. Look at the golden signals for the affected service and its dependencies. Mitigate the biggest harm with the safest action, often a rollback or a feature flag, before understanding the cause. Preserve logs and dashboards and keep a timestamped timeline for the postmortem.
Example
Checkout errors spiked to 30 percent at 09:12; the commander declared a sev-1, the comms lead posted a status update, and the responders found a config deploy at 09:08 that changed a timeout. Rolling it back at 09:19 restored the error rate; the root cause, a downstream service that now needed the longer timeout, was investigated afterwards with the timeline intact.
Common mistakes
- Debugging the root cause while users are still failing.
- Having everyone in one channel with no commander and five people making changes.
- Restarting services before capturing logs and losing the evidence.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.