Latency, traffic, errors, and saturation. Latency is how long requests take, split between successful and failed calls. Traffic is demand, such as requests per second. Errors is the rate of failed requests, including the ones that return 200 with a broken body. Saturation is how full your most constrained resource is. Instrument errors and latency first because they map directly to user pain.
Why interviewers ask this
It is a fast filter for whether you have a mental model of observability or just a list of tools. The follow through matters more than the recall: interviewers want to hear that you split latency by success and failure (fast failures otherwise flatter your numbers), that saturation is about the constrained resource rather than a generic CPU graph, and that you start with signals users feel.
How to structure your answer
- List all four crisply before you elaborate on any of them.
- Add the nuance that failed request latency must be separated out.
- Say which resource you would treat as the saturation signal and why.
- Prioritize errors and latency for a new service and justify the order.
Example answer
Latency, traffic, errors, saturation. On a new service I would wire errors and latency first, because those are the two a user can feel, and I would make sure latency histograms are split by outcome. That caught us once: our p99 improved after a bad deploy, and it was only because a chunk of requests were failing in 12ms instead of succeeding in 800ms. Traffic goes in next, mostly because it gives every other signal context, and it lets you spot a drop to zero, which is the alert people forget to write. Saturation is the one that takes real thought. For a stateless API it was usually our database connection pool rather than CPU, so we exported pool wait time and in use connections. Generic node CPU never told us anything useful. Once those four are up, everything else is a refinement rather than a new dashboard.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you define saturation for a queue based worker?
- Which of the four would you alert on, and which are dashboard only?
- How do you catch a request that returns 200 but is functionally an error?
Related site reliability engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions