# SLOs and Error Budgets. Alert on Burn Rate, Not Noise. > Define what working means for your services, measure it continuously, and alert on how fast you are burning error budget instead of on every error. Source: https://openobserve.ai/slo/ --- 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. - [Start Free Cloud Trial](https://cloud.openobserve.ai/web/login/) - [Read the docs](/docs/user-guide/analytics/slos/) ### 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. ## Alert on What Your Users Actually Feel ### Define What Good Means - **Good Is a Query, Not a Checkbox** - A scope filter sets the denominator, a good-when predicate picks the numerator, a live preview splits good from bad as you type. - **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. [Learn More](https://openobserve.ai/docs/user-guide/analytics/slos/) ### Alert on Burn Rate - **Burn Rate Puts Failures in Proportion** - At 1 you finish the window having used exactly your allowance, at 14.4 a 30-day budget is gone in about two days. - **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. [Learn More](https://openobserve.ai/docs/user-guide/analytics/slos/) ### Group by Dimension - **One Series per Group** - Group by region, endpoint, or tenant and each one gets its own SLI, budget, and burn rate. - **The Overall Number Is Measured, Not Summed** - The headline SLI is computed on its own, so it never silently becomes the sum of whichever groups fit. [Learn More](https://openobserve.ai/docs/user-guide/analytics/slos/) ### One Measurement, Many Alerts - **Measurement and Paging Stay Apart** - An SLO only measures, alerting on one is an ordinary alert with the same destinations and severity as everything else. - **Three Urgencies, One Objective** - Fast burn pages you, mid burn notifies a channel, slow burn files a ticket. [Learn More](https://openobserve.ai/docs/user-guide/analytics/slos/) ## Measured against industry leaders Same telemetry, same workloads, one platform. Every number is OpenObserve against a named vendor - not an industry average. 8x cost reduction means you can unify your observability into a single platform. 140x storage means longer retention doesn't necessarily mean expensive bills. 5x to 15x faster queries mean dashboards load in milliseconds, not minutes. See how much you would save switching today. - [See all comparisons](/comparison/) ## Teams trust OpenObserve to hold them to their objectives ## SLO FAQs ### 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. ### Can I define SLOs in OpenObserve the way I would in Dash0 or Datadog? Yes. SLOs and error budgets in OpenObserve are defined on the same logs, metrics, and traces you already ingest, with burn-rate alerting built in. Unlike Dash0 or Datadog, the SLO feature is part of the open-source platform, works self-hosted, and does not add per-signal or per-host charges. ## Explore guides, videos, and articles to help you get the most out of SLOs. ### SLOs in OpenObserve [Learn more](https://www.youtube.com/watch?v=a1o2oFhfbkU) ### Monitor Service Reliability with SLOs [Learn more](/docs/user-guide/analytics/slos/) ### SLOs & Burn-Rate Alerts [Learn more](/blog/slos-and-alerts-release/) - [Explore All Blogs](/blog/) ## Ready to get started? Stop letting customers find your outages first. - [Get Started For Free](https://cloud.openobserve.ai/web/login/) - [Schedule Demo](/demo/)