Monitoring with SLOs and error budgets

WHAT THIS TESTS This assesses whether you understand SRE reliability practice: measuring what users feel and using an error budget to drive decisions, instead of reactive threshold alerts.

A GOOD ANSWER COVERS Start from the user. Define Service Level Indicators, measurable signals of user experience such as the proportion of successful requests, request latency under a threshold, or data freshness. Set Service Level Objectives as a target for each SLI over a rolling window, for example that 99.9 percent of requests succeed over 28 days. The complement of the SLO is the error budget, the amount of unreliability you are allowed to spend. Rather than paging on raw CPU or a single spike, alert on burn rate, how fast you are consuming the error budget, with fast-burn alerts for acute outages and slow-burn alerts for gradual degradation. This ties every page to actual user impact. The error budget becomes a shared currency: if the budget is healthy, teams can ship features and take risks; if it is exhausted, the team prioritizes reliability work and slows risky changes. Benefits include far less alert fatigue, objective prioritization between velocity and stability, and alignment between engineering and product on acceptable reliability.

COMMON WRONG ANSWERS Alerting on every internal resource metric, generating noise and fatigue. Setting 100 percent as the target, which is impossibly expensive and leaves no budget for change. Choosing SLIs that do not reflect user experience. Treating SLOs as vanity dashboards with no link to decisions. Ignoring burn-rate alerting in favor of static thresholds.

LIKELY FOLLOW-UPS Why not aim for 100 percent availability? How do fast-burn and slow-burn alerts differ? Who owns the error-budget policy? How do you choose the SLO window length?

ONE CONCRETE EXAMPLE A checkout API targets 99.9 percent success over 28 days. A multi-window burn-rate alert pages only when the budget is being consumed fast enough to breach soon, so a brief CPU spike with no user errors wakes nobody, but a sustained increase in failed requests does, focusing on-call attention strictly on user-impacting problems.