SLOs and error budget
An SLO (service level objective) is the availability you aim for, for example 99.9 % over 30 days. OKStatus turns it into an error budget — the downtime that objective allows — shows how much of it is left, and warns you before it runs out.
Available on the Max and Enterprise plans. There is one setting: the objective. The window (30 rolling days), the budget and the alerts follow from it.
SLA or SLO?
Section titled “SLA or SLO?”The SLA is what you promise your customers; it is what the SLA reports measure. The SLO is your internal objective, usually stricter, so that you react before the SLA is at risk. Setting an SLO changes nothing in your reports.
The error budget
Section titled “The error budget”The budget is the downtime the objective allows over 30 days:
| Objective | Downtime allowed over 30 days |
|---|---|
| 99 % | 7 h 12 min |
| 99.5 % | 3 h 36 min |
| 99.9 % | 43 min |
| 99.95 % | 21 min |
Any objective between 50 % and 99.999 % is accepted.
What counts
Section titled “What counts”- Downtime only, decided exactly as for the uptime figures: a monitor is down when a majority of its regions confirm the failure. A slow monitor is not down — response time alerts cover slowness.
- Planned maintenance does not count: downtime inside a maintenance window of the monitor is left out.
- The window rolls: it always covers the last 30 days. An outage gives its time back 30 days later, so the budget refills on its own.
- Availability on the SLO screens is
1 − downtime ÷ 30 days, so “objective met” and “budget left” always agree.
Set an objective on a monitor
Section titled “Set an objective on a monitor”Open the monitor (Edit, or Add monitor) and go to the Alerts step. Under Availability objective (SLO), pick 99 %, 99.5 %, 99.9 % or 99.95 %, or type your own value. The form shows the budget it gives (“43 min of downtime allowed over 30 days”) and, for an existing monitor, whether the objective would have held over the last 30 days. None removes the SLO.
Set an objective on a group
Section titled “Set an objective on a group”A group often stands for a service: “Payments” = API + webhooks + back office. Open the group (⋯ → Edit) and pick its objective. The rule is simple: the group is down whenever one of its monitors is. Two monitors down at the same time count once. Each monitor keeps its own SLO if it has one.
The group’s notices go to the group’s alert channels, set in the same dialog.
Many monitors at once
Section titled “Many monitors at once”- On the SLO page, choose Set SLOs (or the Type → Without SLO menu and the selection button), tick the monitors, pick an objective and Apply. Before applying, the list shows for each monitor whether it would have held that objective over the last 30 days.
- On the Monitors list, select monitors and use SLO ▾ in the selection bar, next to Group ▾.
- For large fleets, set
sloTargetthrough the API or Terraform (see below).
Where to read the budget
Section titled “Where to read the budget”- The SLO page (sidebar, under Monitors): every SLO, monitors and groups, worst first — objective, availability over 30 days, budget left and when it runs out at the current pace. The KPI row counts the SLOs on track, at risk and exhausted.
- The monitor page: the period bar shows the monitor’s SLO instead of the organization’s SLA target, and an Error budget card shows what is left, the downtime used, the projection and the budget left over the last 30 days.
- The group header on the Monitors list: “SLO 99.5 % · budget 71 %”.
An SLO is at risk when less than 25 % of its budget is left, or when it would run out within 7 days at the pace of the last 7 days.
Alerts
Section titled “Alerts”Three notices, nothing to configure. They are sent on the monitor’s channels (or the group’s), at most one per evaluation (every 5 minutes):
| Notice | Sent when |
|---|---|
| Burning fast | 2 % of the 30-day budget gone in the last hour, or 5 % in the last 6 hours (and at least one minute of downtime). Repeated at most every 6 hours. |
| 75 % used | Three quarters of the budget are gone. Sent again only after it drops back under 70 %. |
| Exhausted | The objective is no longer met. Sent again only after it drops back under 90 %. |
There is no “recovered” message: the budget comes back slowly, on its own, and a message for it would be noise. There is no escalation either — an SLO notice is a warning, not an incident. Muted or paused monitors send none.
SLO notices go to e-mail, webhooks and the chat channels (Slack, Discord, Microsoft Teams, Google Chat, Mattermost, Rocket.Chat, Telegram, ntfy, Pushover). Incident tools (PagerDuty, Jira, Jira Service Management, incident.io, Alertmanager, Splunk, Grafana IRM), SMS and mobile push do not receive them: they are for pages, and a budget notice is not one.
Status pages
Section titled “Status pages”SLOs and budgets are never shown on public status pages.
Below Max, the SLO block in the forms and the SLO page are visible but locked, with a link to the plans. If the organization moves to a lower plan, its SLOs are kept but no longer evaluated, and they can still be removed.
API, Terraform and MCP
Section titled “API, Terraform and MCP”| What | REST API | Terraform | MCP |
|---|---|---|---|
| A monitor’s objective | sloTarget on monitors (null removes it) | slo_target on okstatus_monitor | slo_target on create_monitor, update_monitor |
| A group’s objective | sloTarget on monitor groups | slo_target on okstatus_monitor_group | update_monitor_group |
| Budgets | GET /api/v1/slos, GET /api/v1/monitors/:id/slo | — | list_slos |
Terraform manages the objective, not the budget: a figure that changes every minute has no place in a Terraform state.