Do I need recording rules and a generator to make this work?

No. The SLO is a native object with a target, a window, and an error budget. Alerts point at it directly and inherit the destinations, silence, and severity you already configure on every other alert.

Can I change the target later without losing measurement history?

Yes. The target is applied when the SLO is read, not when a slice is written, so moving from 99.5% to 99.9% re-derives every budget and burn-rate figure instantly from measurements you already have. Editing the SLI itself, the stream, scope, good-when predicate, slice interval or grouping, mints a new generation and rebuilds, and the form tells you before you save.

We already have objectives on another platform. Do we re-derive everything?

No. The burn-rate arithmetic is the Google SRE workbook math, with the long window at twelve times the short. Existing objectives and thresholds transfer as they are.

Count or time slice, which do I pick?

Ask what should happen if traffic stops for ten minutes. A Count SLI sees zero good out of zero total and the ratio is untouched, which is right for request success rates. A time slice SLI counts those ten minutes as ten minutes not proven healthy, which is right for latency and freshness. Alert-based SLIs appear in the interface and are disabled in this release.

What happens if the measurement itself breaks?

The SLO freezes rather than guessing. Coverage is the fraction of expected slices actually measured, and below the 90% floor every derived figure renders as an em dash while attached alerts neither fire nor resolve. A search outage will not credit two hours of downtime as uptime, and it will not clear a page you already have.

SLOs and Error Budgets. Alert on Burn Rate, Not Noise.

Count and time-slice SLIs. Rolling 7, 30, or 90 days.

Define what working means for your services, measure it continuously, and alert on how fast you are burning error budget — on the same engine that already holds your logs, metrics, and traces.

Read the docs

OpenObserve SLO dashboard showing error budget and burn rate

Measure what you promised

Define good as a query, pick a target, get an error budget for the difference.

Alert on speed, not noise

Burn-rate alerts fire on sustained damage and ignore the two minute spike.

One engine, not three tools

SLOs run on the same backend already holding your logs, metrics, and traces.

Reliability & Error Budgets

SLOs in OpenObserve

Define what good means

Good is a query, not a checkbox
A scope filter sets the denominator. A good-when predicate picks the numerator out of it. A live preview splits good from bad on real data as you type, so you find out the definition is wrong before you save it, not a week later.
A real number on day one
Count SLIs cover request success rates. Time slice SLIs cover latency and freshness. Windows are rolling 7, 30, or 90 days, and backfill runs the moment you save, newest first, so you get a real number now instead of waiting a full window to see one. Alerts stay frozen until coverage clears the floor, so nobody gets paged by a half-filled window.

Learn More

Alert on burn rate

Burn rate puts failures in proportion
Burn rate is the multiple of budget-neutral spending. At 1 you finish the window having used exactly your allowance. At 14.4 a 30 day budget is gone in about two days. A two minute spike barely moves the number, a sustained degradation eventually consumes it.
Two windows, so alerts resolve when incidents do
The long window establishes the problem is real and sustained. The short window confirms it is still happening. Long runs at twelve times short, which is what stops a burn-rate alert from hanging around for hours after the incident is over.

Learn More

Group by dimension

One series per group
One number tells you something is wrong, not what. Group by region, endpoint, or tenant and each one gets its own SLI, its own budget, and its own burn rate.
The overall number is measured, not summed
Group totals can be capped or incomplete. The headline SLI is computed on its own, so it never silently becomes the sum of whichever groups fit.

Learn More

One measurement, many alerts

Measurement and paging stay apart
An SLO only measures. Alerting on one is an ordinary alert, carrying the same destinations, silence, and severity as everything else you run.
Three urgencies, one objective
Fast burn pages you, because ×14.4 empties a 30 day budget in two days. Mid burn notifies a channel, slow burn files a ticket.

Learn More

0×

more cost-effective vs. Datadog

8x cost reduction means you can unify your observability into a single platform.

Datadog

OpenObserve

See how much you'd save switching today.

Calculate Your Savings

Testimonials

Teams trust OpenObserve to hold them to their objectives

Correlate between the environments and signals across various sources with OpenObserve built-in correlation engine.

“[OpenObserve is] super fast, definitely very lightweight, and you can get started with an initial POC in two to three minutes to be honest.”

2–3 min

To first POC

Lightweight

Minimal footprint

AI vision

Retail analytics platform

SLO FAQs

: No. The SLO is a native object with a target, a window, and an error budget. Alerts point at it directly and inherit the destinations, silence, and severity you already configure on every other alert.
: Yes. The target is applied when the SLO is read, not when a slice is written, so moving from 99.5% to 99.9% re-derives every budget and burn-rate figure instantly from measurements you already have. Editing the SLI itself, the stream, scope, good-when predicate, slice interval or grouping, mints a new generation and rebuilds, and the form tells you before you save.
: No. The burn-rate arithmetic is the Google SRE workbook math, with the long window at twelve times the short. Existing objectives and thresholds transfer as they are.
: Ask what should happen if traffic stops for ten minutes. A Count SLI sees zero good out of zero total and the ratio is untouched, which is right for request success rates. A time slice SLI counts those ten minutes as ten minutes not proven healthy, which is right for latency and freshness. Alert-based SLIs appear in the interface and are disabled in this release.
: The SLO freezes rather than guessing. Coverage is the fraction of expected slices actually measured, and below the 90% floor every derived figure renders as an em dash while attached alerts neither fire nor resolve. A search outage will not credit two hours of downtime as uptime, and it will not clear a page you already have.

Resources

Explore guides, videos, and articles

to help you get the most out of SLOs.

VIDEO

SLOs in OpenObserve

DOC

Monitor Service Reliability with SLOs

BLOG

SLOs & Burn-Rate Alerts

Explore All Blogs

SLOs and Error Budgets. Alert on Burn Rate, Not Noise.

Measure what you promised

Alert on speed, not noise

One engine, not three tools

SLOs in OpenObserve

Define what good means

Good is a query, not a checkbox

A real number on day one

Alert on burn rate

Burn rate puts failures in proportion

Two windows, so alerts resolve when incidents do

Group by dimension

One series per group

The overall number is measured, not summed

One measurement, many alerts

Measurement and paging stay apart

Three urgencies, one objective

Teams trust OpenObserve to hold them to their objectives

SLO FAQs

Do I need recording rules and a generator to make this work?

Can I change the target later without losing measurement history?

We already have objectives on another platform. Do we re-derive everything?

Count or time slice, which do I pick?

What happens if the measurement itself breaks?

Explore guides, videos, and articles

SLOs in OpenObserve

Monitor Service Reliability with SLOs

SLOs & Burn-Rate Alerts

Ready to get started?