The service recovered. The error budget remembers.
On Growth, Enterprise, and self-hosted Logfire, turn a target into a live error budget and get alerts on sustained burn instead of every blip. Define good from telemetry records or metrics, including model quality and provider availability.
Trusted by teams building production software and AI
Define good
Use the telemetry your application already records
A service level objective says how often a service should behave acceptably over a rolling window. Its SLI decides what counts as good, and the
error budget is everything the target allows to go wrong.
In Logfire, a record-based SLI can use SQL predicates over telemetry records. Use latency and exceptions, or record a business outcome,
evaluation score, or provider name. Metric-based targets can sum a counter or gauge you already record. A record-based target can describe
checkout reliability or model quality without exporting another metric first.
A good checkout request
-- What counts as a "good" request?
duration <0.3andnot is_exception
and attributes->>'http.route'='/checkout'
Setup
Four steps, and the alerts are written for you
Name it
An SLO is a contract between the people who build a service and the people who depend on it, so it needs a name they will both recognize. Checkout availability, not slo-prod-3.
Say what counts as a "good" request
This is the SLI. Choose telemetry records or metrics. For records, start from an availability, latency, AI provider availability, or AI evaluation quality template, or write the good and total SQL conditions yourself. Metrics can use a counter or gauge you already record.
Set the target and the window
Pick the objective and the rolling window: 1, 7, 28, 30 or 90 days. Choosing 99.9 percent over 30 days is also choosing to accept about 43 minutes of failure, which is a more useful conversation to have deliberately at setup than during an incident.
Choose where the alerts go
The burn-rate alert tiers are created for you from the objective and window, routed to the channels you pick. Nothing to compose, and nothing to remember to add later, which is usually where the SLO practice quietly dies.
Try it on your stack
Create an SLO from your telemetry
Start free with 10 million spans, logs, and metrics each month. No credit card required.
Templates cover availability and latency. The useful custom targets are specific to your application: good means the order was written and the confirmation email queued, or good means this tenant's request finished inside its contractual limit. If you can query the telemetry record, you can hold yourself to it.
Error budgets, not just a percentage
Every SLO carries how much budget is left, how fast it is going, and when it runs out at the current rate. That reframes the incident conversation from whether something broke to whether you can afford it, which is the question product and engineering can actually answer together.
Multi-window, multi-burn-rate alerts
Straight from the Google SRE workbook: a fast tier at 14.4 times normal burn over 1 hour with a 5 minute short window, a medium tier at 6 times over 6 hours with a 30 minute window, and a slow tier at 1 times over 3 days with a 6 hour window. The first two page, the third opens a ticket. Tiers that could never fire for your objective and window are skipped rather than created and left to be muted.
SLOs over AI behavior
Define a good run as one your judge scored above a threshold, or scope availability to a single model provider so one vendor's outage does not spend the budget for the path that was fine. Evaluation events and model-call spans share the same query surface, which lets one SLO reason about both.
One-click provider SLOs
Availability SLOs for OpenAI, Anthropic, Google or any other provider you call, without writing the predicate yourself. Useful the first time a provider has a bad afternoon and you need to say how much of it your users actually felt.
SLOs as code
Manage them through the public API so an SLO lives in the same repository as the service it describes, gets reviewed in a pull request, and is recreated with the service rather than remembered. Clicking through a wizard is the right way to make your first one and the wrong way to make your fortieth.
The difference
Objectives over how well your models behave
Metric-backed objectives are useful, but they are not the only option. A record-based SLI can query telemetry directly, so evaluation events and
model-call spans can define an objective about quality rather than only uptime:
AI quality and per-provider availability
-- AI quality: a run is "good" when the-- judge scored it at or above threshold.cast(attributes->>'gen_ai.evaluation.score.value'asdouble) >=0.8-- AI availability: scoped to one provider.
attributes->>'gen_ai.provider.name'='anthropic'andnot is_exception
Scoping to one provider matters more than it sounds like it should: without it, an Anthropic outage spends the error budget for your OpenAI
path, and the number stops describing anything.
SLOs also suit AI features better than threshold alerts do, for the same reason they suit anything variable. Model behavior fluctuates, and a
budget tolerates fluctuation while still catching a real trend. A threshold just fires.
Why burn rate
Thresholds fire on blips and sleep through decay
A threshold alert fires whenever the number crosses the line. That means it wakes someone for a ninety-second blip that cost almost none of the
budget, and stays quiet through a slow degradation that will exhaust the budget by Thursday. Severity has no relationship to consequence.
Burn rate measures how fast you are spending the budget instead, which is why the Google SRE workbook recommends it. Fast burn pages, slow burn opens a ticket, and a blip that cost nothing does neither. Logfire generates those tiers from your objective
and window rather than leaving you to derive the multipliers.
This window crossed the 6× medium-burn line and has since returned below 1×. The same view gives you the latest rate, the peak and whether a managed alert is active, so the chart answers both what happened and whether anyone still needs to act.
FAQ
Common questions
What is an SLO?
A service level objective is a target for how often a service behaves acceptably, measured over a window. It has three parts: an SLI, which is the measurement of what counts as a good request; the objective, which is the percentage you are aiming for; and the error budget, which is what is left over. A 99.9 percent objective over 30 days is also a statement that roughly 43 minutes of failure is acceptable, and being explicit about that is the whole point.
What is an error budget?
The error budget is the failure your objective permits. At 99.9 percent, one request in a thousand is allowed to be bad, and the remaining budget shows how much of that allowance is left in the current window.
How do I define what counts as a good request?
Choose telemetry records or metrics. Record-based templates cover availability, latency, per-provider AI availability, and AI evaluation quality; beyond those, write the good and total SQL conditions yourself. Metric-based targets can sum a counter or gauge you already record.
How does burn-rate alerting work?
Logfire creates the multi-window multi-burn-rate alerts from the Google SRE workbook: a fast tier comparing a 1 hour and 5 minute window at 14.4 times normal burn, a medium tier at 6 hours and 30 minutes at 6 times, and a slow tier at 3 days and 6 hours at 1 times. The first two are pages, the third is a ticket. Tiers that could never fire for a given objective and window are skipped rather than created and left to be muted.
Why not just alert on a threshold?
A threshold alert fires whenever the number crosses the line, which means it fires on a brief blip that consumed almost none of your budget and stays quiet during a slow degradation that will exhaust it by Thursday. Burn-rate alerting measures how fast you are spending the budget, so severity tracks consequence. That is why the SRE workbook recommends it over static thresholds.
Can I set an SLO on an LLM feature?
Yes. Evaluation results arrive as OpenTelemetry events and model calls as spans, and both are queryable telemetry records, so you can define a good run as one where the judge scored above a threshold or scope availability to a single provider. SLOs suit AI features well precisely because model behavior is variable, and a budget tolerates variance where a threshold alert would just be noisy.
What time windows are supported?
Logfire supports rolling windows of 1, 7, 28, 30 and 90 days. A 30-day window gives teams a continuously current monthly view, while shorter windows make fast-moving objectives easier to inspect. Burn-rate charts resolve to hourly buckets across those windows.
Can I manage SLOs as code?
Yes, through the public API, so an SLO can live in the same repository as the service it describes and be reviewed like anything else. That matters once you have enough of them that clicking through a wizard stops being the fastest path.
Put a number on what good looks like
Get started with 10 million free spans, logs, and metrics per month. No credit card required.
