SLO monitoring that turns reliability into a shared number

What is SLO monitoring?

SLO monitoring tracks whether a service meets its service level objectives. A service level indicator (SLI) measures one aspect of user experience, typically the ratio of good events to all events, for example successful requests or requests faster than 300 ms. A service level objective (SLO) sets a target for that SLI over a time window, such as 99.9 percent over 28 days. The difference between the target and 100 percent is the error budget: the amount of unreliability the service may have before users are noticeably affected.

SLOs move the conversation from individual alerts and charts to a single question: are we reliable enough for our users right now, and how much risk can we still take?

Why SLO monitoring matters

Without SLOs, reliability is either undefined or set to an implicit 100 percent. Teams then react to every spike, alert on causes rather than symptoms and argue about whether a release is too risky. SLOs replace that with an agreed number. When the error budget is healthy, teams can ship faster and experiment. When it is spent, reliability work takes priority.

SLOs also improve alerting. Instead of static thresholds on individual metrics, burn-rate alerts measure how fast the error budget is being consumed, which correlates directly with user impact.

SLIs, SLOs and error budgets in practice

• Availability SLI: share of requests that return a success status.
• Latency SLI: share of requests completed below a defined threshold.
• Quality SLI: share of responses that are complete and correct, for example search results without fallback.
• Freshness SLI: share of data updates processed within a target delay, useful for pipelines and queues.

An SLO of 99.9 percent over 28 days allows about 40 minutes of full unavailability, or a larger number of partial errors spread over the period. Obseria calculates the budget and its consumption continuously.

Multi-window burn-rate alerts

The burn rate describes how fast the error budget is used relative to the SLO window. A burn rate of 1 uses exactly the budget by the end of the window; a burn rate of 14.4 would use a 28-day budget in about two days. Multi-window alerts combine a long window, which confirms the problem is significant, with a short window, which confirms it is still happening. This catches serious incidents quickly and avoids pages for short spikes that have already recovered.

(1 - sum(rate(http_requests_total{service="checkout",code!~"5.."}[1h]))
   / sum(rate(http_requests_total{service="checkout"}[1h]))) / (1 - 0.999) > 14.4

Obseria creates fast-burn and slow-burn alerts for each SLO automatically and routes them through the same alerting rules, on-call integrations and incident workflows as every other alert.

How Obseria handles SLO monitoring

SLIs in Obseria can use any signal in Obseria Lake: Prometheus and OpenTelemetry metrics, trace spans, logs or synthetic checks. TopoGraph links each SLO to its service, so you see which dependencies contributed to budget consumption and which deployments preceded it. When an SLO burns, Obseria Intelligence can start a root cause investigation and present its chain of evidence.

Release gates connect error budgets with delivery. Your CI/CD pipeline asks Obseria whether a service is within budget before deploying, and can warn or block when the budget is exhausted. SLOs are defined through the UI, the API, the CLI or Terraform, so they can live in the same repository as the service.

SLO best practices

1. Start with few SLOs. One availability and one latency SLO per critical user journey is enough at first.
2. Measure close to the user. Load balancer, gateway or client-side data reflects experience better than internal metrics.
3. Set realistic targets. Base objectives on current performance and user expectations, not on 100 percent.
4. Agree on budget policies. Decide in advance what happens when the budget is spent.
5. Review regularly. Adjust SLIs and targets as the product and its users change.