SLOs: objectives, error budgets and unmeasured time

A service level objective (SLO) is a promise you make about one thing Belvador already measures: "the checkout API answers 99.9 % of the time", "the nightly export succeeds 99 % of runs", "95 % of GET /api/orders requests finish under 300 ms". Belvador counts good and bad over a rolling window, shows how much error budget is left, and alerts you when the budget is burning too fast — long before it is gone.

1. Create an SLO#

Open SLOs → New SLO and work through the four steps.

1. Source — what is counted:

   Source	Good	Total	Counted by
   Uptime check · availability	rounds that were Up or Degraded	rounds with a definite result	Belvador, from the check's results
   Uptime check · latency	rounds answered within your threshold	rounds with a definite result	Belvador
   Monitor	runs that ended OK	runs that ended OK, failed, timed out or were missed	your node
   Heartbeat	deadlines met by an on-time ping	deadlines that passed	Belvador
   Spans · availability	SERVER spans without error status	SERVER spans of the service (and operation)	your node
   Spans · latency	SERVER spans faster than your threshold	SERVER spans of the service (and operation)	your node

   Spans count only the SERVER kind, so a request is not counted twice through its client and internal spans. A monitor or spans SLO can be limited to one environment; empty means every environment.

2. What counts as good — availability, or latency with a threshold of 1–60000 ms (uptime checks and spans only).

3. Objective — between 90 % and 99.99 %, over a rolling window of 7, 28, 30 days. The form shows the budget this gives you, for example "Error budget: 43.2 minutes per 30 days" for 99.9 %.

4. Alerts — which burn levels may alert; see Burn-rate alerts.

Belvador measures from the moment you save; history from before is not filled in. A new SLO needs at least 60 measured minutes before it shows a verdict. How many SLOs a workspace can have depends on its plan.

2. Error budget#

The error budget is the bad you are allowed: 1 − objective of the window. How it is spent depends on the source, using the two OpenSLO budgeting methods:

• Timeslices (uptime checks) — the budget is time. 99.9 % over 30 days allows 43.2 bad minutes; every bad interval spends its length.

• Occurrences (monitors, heartbeats, spans) — the budget is a share of events. 99 % allows 1 bad run in every 100.

Budget left is shown in percent and can go below zero when the SLO is already missed. Attained is good ÷ total over the window, always rounded down, so a value just under the target never reads as meeting it.

3. Unknown time never counts as good#

Some minutes cannot be judged: the node was offline, an uptime round had too few regions, the source was paused, or nothing ran. Belvador leaves those minutes out of both good and total — they are never counted as good.

Coverage is the share of the window Belvador could measure. Below 90 %, the SLO shows Not enough data instead of a number, and it sends no alerts. Gaps are drawn as gaps in the budget chart.

4. Statuses#

5. Editing an SLO#

Every save creates a new revision, listed on the SLO page. Changing the name, description, objective, window or alert policy keeps the history. Changing what is counted — the source, its filters, the indicator, the latency threshold or whether public sources count — starts the budget again from that moment, because old counts no longer mean the same thing. The form warns you before you save.

An SLO imported from an OpenSLO file can only be changed by importing the file again.

6. Public sources#

Some data can be sent with a key that is public by design — for example check-ins sent with a browser DSN. Anyone who can read your page could send fake values and move the SLO. Such data is not counted unless you turn on Allow public sources for that SLO; the SLO then carries a warning label.

7. Where SLO data lives#

• Kept by Belvador: the definition and its revisions, and counts only — per SLO and minute, how many were good and how many were counted. Minute counts are kept for 3 days, hourly counts for 90 days. Windows up to 6 hours are judged from minute counts, longer ones from hourly counts. Status and alert history are kept with them.

• Never sent to Belvador: span contents, check-in contents or anything else from your node. For monitor and spans SLOs your node receives only the SLO's id and filter, counts locally, and sends (SLO id, good, total) per minute. It never learns the SLO's name.

• Spans are counted 3 minutes after each minute ends, so late batches still land in the right minute.

8. Not in this version#

Calendar-month windows, SLOs combining several sources, weighting by sampling rate and scheduled exclusions are not supported. For planned maintenance, mute or pause the SLO.