# OpenObserve Introduces SLOs, Grouped Alerts, and Terraform/GitOps Support

> Native SLOs with error budgets and multi-window burn-rate alerting, alerts that track each host or metric series independently, and bidirectional Terraform and GitOps support.

Source: https://openobserve.ai/whats-new/2026-08-19-slos-and-alerts/
Published: 2026-08-19
Version: Cloud
Tags: slo, slos, alerting, error-budget, burn-rate, terraform, gitops, reliability

---

![Service Level Objectives in OpenObserve](/img/slos-in-openobserve.png)

OpenObserve now supports SLOs (Service Level Objectives) as a native object under **Reliability**, with error budgets and burn-rate tracking built in, instead of something teams approximate with a dashboard panel and a threshold alert. Define one with a **Count** SLI (good events over total, for success rates) or a **Time Slice** SLI (a per-slice condition like p95 under 500ms, for latency and freshness), set a target and rolling window, and OpenObserve measures against historical data immediately.

[The Terraform provider](https://openobserve.ai/docs/enterprise-setup/terraform/) is now bidirectional, export existing configuration as code or provision alerts, dashboards, SLOs, IAM, streams, and users directly from code, with GitOps support via the existing Kubernetes operator, Terraform, or OpenTofu.

Grouped alerts get a new toggle: enable per group alerting on an alert you already have, no new alert to create, no rewrite, and each host, or each PromQL series from the query's own group-by, gets its own independent state instead of collapsing into one verdict where a single host recovering used to silence the rest of the group.

SLOs, the alerting changes, and Terraform/GitOps support are live in OpenObserve Cloud today. Read the [SLOs documentation](https://openobserve.ai/docs/user-guide/analytics/slos/) or [contact us](https://openobserve.ai/contact/) with questions.