SLI, SLO, and Error Budget Monitoring with SQL

A service-level indicator (SLI) measures an outcome users experience. A service-level objective (SLO) sets a target for that indicator over a defined window. An error budget is the amount of allowed failure implied by the objective.

Start with a bounded application outcome such as an API request, checkout, job, or webhook delivery. Infrastructure availability is useful context, but a healthy host does not prove that the customer workflow succeeded.

Define the event contract

For a request-based availability SLI, emit one terminal event with:

• event_id;
• timestamp_utc;
• service and route_template;
• status and status_code;
• latency_ms;
• environment and release;
• a controlled error_type;
• an optional safe account_id for impact analysis.

Document eligibility. Health checks, synthetic traffic, canceled requests, and expected client errors may or may not belong in the denominator. The decision must be consistent across the query, dashboard, and alert.

Calculate availability compliance

The SLO availability SQL recipe separates eligible requests, good requests, bad requests, and compliance percentage. Use it with a complete observation window and a reviewed good-event definition.

For a 99.9% objective, the allowed bad fraction is 0.001. An error budget measured in requests is:

eligible_requests * (1 - objective)

Keep counts beside percentages. A 50% failure rate from two requests and a 2% failure rate from one million requests require different interpretation.

Monitor burn rate

Burn rate compares the observed bad-event fraction with the allowed bad fraction. A burn rate of 1 consumes budget at exactly the planned rate. A burn rate above 1 consumes it too quickly.

The error-budget burn recipe calculates the value over time buckets. Pair a short window, which detects fast incidents, with a longer window that prevents one noisy bucket from paging the team.

Do not alert on the newest incomplete time bucket unless the query explicitly accounts for partial data. Require minimum eligible volume and sustained evaluation points before triggering.

Add latency and workflow SLIs

Availability is only one user-visible property. A request can succeed after an unacceptable delay. Define a latency SLI as the fraction of eligible requests below a reviewed threshold, or inspect p95 and p99 with the API latency percentile recipe.

For background jobs and webhooks, define success around the terminal business outcome rather than an individual attempt. A recovered retry may consume latency budget without counting as a terminal failure. Keep attempt-level diagnostics available without inflating the SLI denominator.

Build the dashboard and alert path

Place these views together:

1. Eligible request volume and data freshness.
2. SLO compliance for the complete rolling window.
3. Short- and long-window burn rate.
4. Failure breakdown by route, release, and error type.
5. A recent-event table for customer-impact investigation.

Add operating notes that name the owner, objective, denominator, exclusions, and response action. Follow the alert guide for evaluation behavior and the incident-response guide for investigation flow.

Validate before paging

Replay a fixture with known successes, failures, excluded events, and an incomplete newest bucket. Confirm the exact eligible count, allowed failures, compliance, and burn rate. Then observe the alert without notifications before attaching an on-call response.