Site Reliability Engineering interview question · Most asked
What makes a good alert? Explain symptom-based alerting and alert fatigue.
Summary
A good page is urgent, actionable, and indicates real or imminent user impact. Alert on symptoms (users seeing errors or slowness, SLO burn) rather than causes (high CPU on one host), and route non-urgent problems to tickets. Alert fatigue, from too many noisy pages, makes people ignore the alert that matters.
Longer Answer
Every page should answer: is this hurting users or about to? Can the on-call engineer do something now? Is there a runbook? Cause-based alerts are still useful as dashboards or low-urgency tickets, and for imminent saturation (disk full in two hours).
Hygiene: review pages weekly, delete or downgrade alerts that were not actionable, deduplicate and group related alerts, and track pages per shift. Google's guidance is a small number of incidents per on-call shift so each gets proper attention and follow-up.
Key Points
- Pages must be urgent and actionable.
- Symptoms over causes.
- Tickets for non-urgent issues.
- Regularly prune noisy alerts.
More most-asked Site Reliability Engineering questions
- What is Site Reliability Engineering, and how does it relate to DevOps?
- What is the difference between monitoring and observability? Explain metrics, logs and traces.
- What is an error budget, and how should it be used?
- Define SLI, SLO and SLA, and explain how they relate.
- What is burn-rate alerting, and why is it better than alerting on raw error rates?
- How do you choose good SLIs for a service?
- What are the four golden signals?
- How should incident response be organised? Describe the key roles.