Alert on symptoms users feel, defined as service level objectives: availability and latency measured at the edge, plus correctness signals such as failed payments or a queue that stops draining. Page only when an objective is at risk of being missed, using error budget burn rate so a slow drift raises a ticket and a fast burn wakes someone. Keep cause based alerts like high CPU as dashboards, not pages.
Why interviewers ask this
Alerting design tells the interviewer how you have been on call. They want symptom based alerting, an actual objective rather than an arbitrary threshold, and a distinction between what pages a human and what waits until morning. Anyone who has lived with a noisy pager knows that alert fatigue causes outages, so pruning alerts is a legitimate and valued answer.
How to structure your answer
- Anchor alerts to user visible symptoms and objectives.
- Explain error budget burn rate for severity.
- Separate what pages from what becomes a ticket or a dashboard.
- Describe how you keep the alert set healthy over time.
Example answer
I start from what a user would notice: requests failing, requests being slow, and the domain specific things that are worse than either, like orders not being confirmed or a consumer lag that keeps climbing. Those become objectives with a target, say 99.9 percent of requests succeeding and 95th percentile latency under three hundred milliseconds, measured at the load balancer rather than inside the app so I count the failures my code never sees. Then alert severity comes from burn rate: burning the monthly error budget in an hour pages immediately, while a slow burn over days is a ticket. Cause based metrics like CPU, memory or disk stay on dashboards and in capacity alerts, because a busy CPU that nobody feels is not an incident. Every page needs to be actionable, so it links to a runbook, and anything that fired without action gets reviewed. On one team we cut the pager volume by about two thirds that way, and the real win was that the remaining alerts got taken seriously.
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 pick the objective target with the product team?
- What do you do with an alert that fires every week and is always ignored?
- How do you alert on a queue backing up before customers notice?
Related backend developer 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