Define SLOs

How to set Service Level Objectives — availability and performance targets with error budgets and burn rate alerts.

Define SLOs

Service Level Objectives (SLOs) let you define a target for a monitor and track how much error budget remains. When a monitor's success rate drops below the target, Yorker calculates how fast you are consuming error budget and can alert before the budget runs out.

Yorker supports two SLI types:

Availability SLIs — the ratio of successful check runs to total runs. Use this for uptime objectives.
Performance SLIs — the ratio of runs where response time is at or below a threshold. Use this for latency objectives (e.g. "p95 < 500 ms").

Why SLOs matter

Raw uptime percentages hide how much room you have for incidents. An SLO of 99.9% over 30 days gives you an error budget of roughly 43 minutes of downtime. Burn rate alerts tell you when you are spending that budget faster than expected, so you can respond before it is exhausted — rather than reacting after a hard threshold is crossed.

Define an availability SLO

Add an slos block to your yorker.config.yaml. Each SLO references a monitor by name:

project: my-app

alertChannels:
  ops-slack:
    type: slack
    webhookUrl: "{{secrets.SLACK_WEBHOOK_URL}}"

monitors:
  - name: API Health
    type: http
    url: https://api.example.com/health
    frequency: 1m

slos:
  - name: API Availability
    monitor: API Health
    target: "99.9%"
    window: 30d
    burnRateAlerts: true
    channels:
      - "@ops-slack"

SLO fields

Field	Required	Description
`name`	Yes	A unique name for the SLO.
`monitor`	Yes	The name of the monitor this SLO tracks. Must match a monitor defined in the same config.
`target`	Yes	Target. Accepts `"99.9%"` (string with percent sign) or `99.9` (number treated as percentage).
`window`	Yes	Evaluation window. Must be `7d`, `14d`, or `30d`.
`burnRateAlerts`	No	Enable burn rate alerting. Defaults to `true`.
`channels`	No	Notification channels for burn rate alerts. Uses `@channel-name` references to `alertChannels`.
`enabled`	No	Whether the SLO is active. Defaults to `true`.

Target parsing

The target field accepts two formats:

String with percent: "99.9%" — parsed as 99.9%, stored as 9990 basis points.
Number: 99.9 — treated as a percentage, stored as 9990 basis points.

Both formats produce the same result. Basis points range from 1 to 9999 (0.01% to 99.99%).

Window

The evaluation window determines how far back Yorker looks when calculating availability and error budget. Only three values are accepted: 7d, 14d, or 30d (or the equivalent integers 7, 14, 30).

Performance SLOs

Performance SLOs track the fraction of runs whose response time meets a latency threshold. They are available through the REST API and dashboard today — not through yorker.config.yaml. Create one via the API:

curl -X POST https://app.yorkermonitoring.com/api/slos \
  -H "Authorization: Bearer $YORKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sloType": "check",
    "checkId": "chk_abc123",
    "name": "API Latency",
    "targetBasisPoints": 9500,
    "windowDays": 30,
    "sliType": "performance",
    "perfThresholdMs": 500,
    "burnRateAlertsEnabled": true
  }'

Field	Description
`sliType: "performance"`	Use a latency-based SLI. Default is `availability`.
`perfThresholdMs`	Required for performance SLIs. Runs at or below this duration are considered compliant.

Performance SLOs share everything else with availability SLOs — burn rate alerts, error budgets, and evaluation windows.

Third-party SLOs

Yorker can also track SLOs against metrics emitted by services you do not own — external APIs, vendors, dependencies. When the runner observes an outbound call to a third-party host, Yorker extracts metrics and can roll them up into an SLO.

Third-party SLOs are discovered and configured through the dashboard (SLOs > New > Third-party). See the REST API reference for the underlying sloType: "third_party" fields.

Burn rate alerts

When burnRateAlerts is enabled (the default), Yorker continuously calculates how fast error budget is being consumed. The system tracks burn rates over three windows:

1-hour burn rate — detects sudden spikes in failures.
6-hour burn rate — catches sustained degradation.
24-hour burn rate — identifies slow-burn issues.

If the burn rate indicates the error budget will be exhausted before the window ends, an alert fires through the configured channels. Advanced users can also configure custom burn_rate alert conditions directly — see Set Up Alerts.

View SLO status

To view SLO status in the dashboard, navigate to the SLOs section. Each SLO shows:

Current availability or performance ratio
Error budget total, consumed, and remaining
Burn rates at 1h, 6h, and 24h windows
Whether the SLO is currently met

To check SLO status via the API:

curl https://app.yorkermonitoring.com/api/slos/slo_abc123/status \
  -H "Authorization: Bearer $YORKER_API_KEY"

Complete example

project: my-app

alertChannels:
  ops-slack:
    type: slack
    webhookUrl: "{{secrets.SLACK_WEBHOOK_URL}}"
  pagerduty:
    type: webhook
    url: "{{secrets.PAGERDUTY_WEBHOOK_URL}}"

monitors:
  - name: Homepage
    type: http
    url: https://example.com
    frequency: 1m
  - name: Checkout Flow
    type: browser
    script: ./monitors/checkout.ts
    frequency: 5m

slos:
  - name: Homepage Availability
    monitor: Homepage
    target: "99.95%"
    window: 30d
    burnRateAlerts: true
    channels:
      - "@ops-slack"

  - name: Checkout Availability
    monitor: Checkout Flow
    target: "99.9%"
    window: 30d
    burnRateAlerts: true
    channels:
      - "@ops-slack"
      - "@pagerduty"

Set Up Alerts Notification Channels