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.
Logfire for SLOs
Service level objectives, defined by a query
Set an objective, get an error budget, and let the multi-window burn-rate alerts from the Google SRE workbook be generated for you. Because the SLI is a SQL predicate, you can hold yourself to anything you record, including how well your models behave.
-- What counts as a "good" request?
duration < 0.3
and not is_exception
and attributes->>'http.route' = '/checkout'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: the SLI, the measurement of what counts as a good request; the objective, the percentage you are aiming for; and the error budget, which is everything the objective allows you to get wrong.
That last part is why SLOs are worth the trouble. Choosing 99.9 percent over 30 days is also choosing to accept about 43 minutes of failure. Saying so out loud turns "is it broken" into "can we afford this", which is a question product and engineering can answer together.
Four steps, and the alerts are written for you
Say what counts as a "good" request
This is the SLI, and it is a SQL predicate over your spans. Start from a template, availability, latency, AI provider availability, AI evaluation quality: or write the condition yourself. Because it is a predicate rather than a fixed metric, anything you record can define one, including attributes specific to your business.
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.
Budgets, burn rates and the alerts that follow
SLIs from any SQL predicate
Availability and latency are the templates everyone offers. Because an SLI here is just a condition over your spans, the interesting ones are the ones nobody templated: good means the order was written and the confirmation email queued, or good means this tenant's request finished inside their contractual limit. If you can query it, 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.
Objectives over how well your models behave
This is the part no other observability vendor offers today. An SLI here is a SQL predicate over telemetry records, so evaluation events and model-call spans can define an objective about quality rather than only uptime:
-- AI quality: a run is "good" when the
-- judge scored it at or above threshold.
cast(attributes->>'gen_ai.evaluation.score.value'
as double) >= 0.8
-- AI availability: scoped to one provider.
attributes->>'gen_ai.provider.name' = 'anthropic'
and not is_exceptionScoping 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.
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.
Is Logfire right for you?
Choose Logfire if
- You want the SLI to be a query over your data rather than a fixed set of metrics
- You want burn-rate alert tiers generated correctly rather than hand-tuned
- You have AI features and want objectives over model quality or per-provider availability
- You want SLOs, traces, logs and metrics in one product rather than an SLO tool bolted on
- You want to manage SLOs as code alongside the services they describe
Choose a dedicated SLO tool if
- You need calendar-aligned windows, such as an SLO defined as this calendar month
- You need windows longer than 90 days or sub-hourly burn-rate resolution
- Your organization has no SLO practice yet and wants consulting rather than a product
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 budget is how much of that allowance you have left in the current window. It changes the conversation from whether something broke to whether you can afford it, which is what makes SLOs useful to product and engineering at the same time rather than being another alert.
How do I define what counts as a good request?
With a SQL predicate. Templates cover availability, latency, per-provider AI availability and AI evaluation quality, and beyond those you write the condition yourself. Because the SLI is a predicate over your telemetry records, anything you record can define one, including attributes specific to your business rather than only HTTP status and duration.
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, and this is the part no other observability vendor offers. 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?
Rolling windows from a preset list: 1, 7, 28, 30 and 90 days. There are no calendar-aligned windows, so an SLO cannot be defined as this calendar month; the 30-day rolling window is the closest equivalent. The burn-rate chart resolves to hourly buckets.
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.