You are on call and get paged for a high error rate. What are your first steps?

What the interviewer wants to hear

• Acknowledge the page and assess user impact
• Check dashboards and recent changes or deploys
• Mitigate first, for example rollback, before finding root cause
• Communicate and escalate or declare an incident if needed
• Keep a timeline and follow the runbook

Model answer

First I acknowledge the page so others know someone is on it. Then I check how bad the impact is: which endpoints, regions or customers are affected and how fast we are burning the error budget. I open the runbook for that alert and look at dashboards for the golden signals. Very often the cause is a recent change, so I check deploys, config changes and feature flags in the last hour. My priority is to mitigate, not to find the perfect root cause, so if a recent release lines up with the errors I roll it back or turn off the flag. If the impact is large or I am stuck, I declare an incident, pull in help, and post regular status updates while keeping notes for the postmortem.

More easy Site Reliability Engineer questions

• Explain the difference between an SLI, an SLO and an SLA, with an example.
• What is an error budget and how does a team use it?
• What are the four golden signals, and why are they useful for monitoring?
• What is toil, and how would you reduce it on your team?
• What is the difference between monitoring and observability, and what are metrics, logs and traces each good for?
• Why do SRE teams manage infrastructure with code tools such as Terraform instead of clicking in a cloud console?
• Explain blue-green and canary deployments. When would you choose each?
• You are asked to build the main Grafana dashboard for a web API. What would you put on it, and how would you lay it out?
• What makes an on-call rotation healthy and sustainable for the engineers on it?