Service level objectives (SLOs)
Promise how reliable a service is, and see how much room is left before you break it.
1Add an objective
Monitoring → SLOs → New SLO. Choose the environment, then measure availability (which status codes count as good) or latency (how fast is fast enough, in milliseconds), the target and the rolling window. Optionally limit it to one service or route, such as /checkout.
2Read the error budget
The budget is the failures you can afford in the window: 99.9% over 30 days allows about 43 minutes of downtime. Each objective shows how much is left, and whether it’s healthy, running low or exhausted.
3Burn rate
A burn rate of 1 uses the budget exactly by the end of the window; 14 empties a 30-day budget in about two days. Add an alert rule on “SLO error-budget burn rate” (see Alert rules) to hear while there’s still budget left.
4When it’s gone
Slow down risky deploys and spend the time on reliability until the budget recovers.