Objectives
Service level objectives and error budgets, declared in git and derived on a running stack.
An Objective is a statement of intent: this service should be this good, measured this way, over this window. Like a dashboard, it is a declared Kind, authored in git, with no create button in the console. What is derived, continuously, is the error budget burning against it.
Not the same thing as an incident SLA
Incident already tracks how fast humans respond to an incident
(sla_ttack_target_minutes/sla_tttr_target_minutes). An Objective
measures how well the system behaved, not how fast anyone reacted. The two
share the word "SLA" loosely and nothing else.
What an Objective declares
| Field | Meaning |
|---|---|
service or monitor | Exactly one subject. Most Objectives name a service; a monitor not yet bound to a service can also carry one directly. |
sliKind | availability or latency. |
sliSource | synthetic (probe/monitor checks) or requests (real request spans). Switching this later keeps the Objective's identity and history. |
latencyThresholdMs | Required for a latency Objective, and only a latency Objective. Latency is expressed as a threshold ("99% of requests under 300ms"), not a percentile target, because a percentile cannot be re-aggregated over a different window from stored data. |
target | The ratio of good to valid events you're committing to, e.g. 0.999 for 99.9%. Stored exactly, never as a float, so an objective never reports itself as 99.94999% because of binary rounding. |
window | Rolling only: 7d, 28d, 30d, or 90d. Twenty-eight days is the default, because it holds the day-of-week mix constant. Calendar windows ("99.9% in August") are not supported yet. |
alerting | Optional; defaults to a fast/slow/trend multi-window burn-rate policy. The rules that page on a fast burn are generated from this field, never authored separately, so the two cannot drift apart. |
apiVersion: up0.io/v1
kind: Objective
metadata:
name: payments-api-availability
spec:
service: payments-api
sliKind: availability
sliSource: requests
target: 0.999
window: 28dError budget and burn
An error budget is 1 - target: a 99.9% target over 28 days allows 0.1% of
valid events to be bad. Burn rate is how fast that allowance is being
consumed relative to steady state; a burn rate of 14.4 exhausts a 28-day
budget in about an hour.
Alerting compares a long window against a short one so a momentary spike doesn't page: a fast burn (1 hour, confirmed over 5 minutes) pages immediately, a slow burn (6 hours, confirmed over 30 minutes) also pages, and a multi-day trend opens a ticket rather than paging, because it will not matter for days yet.
The budget itself is recomputed roughly every minute, never hand-edited, and a re-run replaces its previous answer instead of double-counting, so fixing a derivation bug is a re-run, not a correction.
What the console shows
- The list: every Objective with its current budget remaining, as a number and a bar. An Objective with no events yet in its window reads as "no data yet," never a fabricated 0%.
- The detail page: budget remaining and burn rate, each as a chart over the Objective's own window, with a marker where the Objective's own definition (its target or window) last changed, so a chart never averages silently across an incomparable boundary.
- On the service: a service's Objectives appear on its own detail page, the same list component as above.
- Manifest and provenance: like every declared Kind, the manifest path and the commit that last applied it.
There is no create button anywhere in this list. The empty state says an Objective is created by committing a manifest, not by a form.
Walked on this account
Blocked at the same step as dashboards
Declaring an Objective needs the same connected repository a dashboard does (see Building a dashboard), which needs a service account and a completed GitHub sign-in this walk could not perform headlessly. This organization's services also haven't been discovered yet: the correlation harness that derives the service catalog from telemetry is disabled on this cluster, so there is no service to point a service-anchored Objective at even once a repository is connected. A monitor-subject Objective has no such dependency on the service catalog, but still needs the same repository connection to be declared at all. What follows is exactly what this account's console offers today, not what a populated one would show.
The Objectives list itself renders correctly and says why it's empty: "An Objective is created by committing a manifest to your repository — it is not created here. This organization has not had one applied yet."