---
title: 'Synthetic Monitoring SLO Tracking'
description: 'Define SLOs on synthetic monitors. Error budgets, burn rate alerts, and SLI dashboards, including SLOs on third-party dependency performance.'
canonical_url: 'https://yorkermonitoring.com/features/slo-tracking'
---

# SLOs on your synthetic monitors

## Including your third-party dependencies

Define error budgets on HTTP checks, browser monitors, and, uniquely, on third-party domains detected across your monitor portfolio. Know your burn rate before your budget is gone.

Yorker is OTel-native synthetic monitoring for developers and SRE teams, built by Reverse Sweep Ltd.

[Start Free](/sign-up) · [Read Docs](/docs)

### Example SLO dashboard

| Monitor | Current / Target | Error budget remaining | Burn rate | Days left | Status |
| --- | --- | --- | --- | --- | --- |
| Checkout Flow | 99.72% / 99.9% | 28% | 4.2x | 6d | Warning |
| API Health | 99.89% / 99.5% | 98% | 0.3x | 27d | OK |
| cdn.tagmanager.net | 97.4% / 99.0% | 12% | 8.1x | 2d | Critical |

## How it works

### 01. Define the SLI

Choose success rate, response time percentile, or Web Vitals threshold as your SLI. Attach it to any HTTP or browser check.

### 02. Set the error budget

99.9% over a 30-day rolling window means 43.2 minutes of allowed downtime. 99.5% means 3.6 hours.

### 03. Monitor tracks actual vs target

The SLO dashboard shows current SLI value, budget consumed, and burn rate, updated on every check run.

### 04. Burn rate alert fires early

Alert when the budget will be exhausted at the current rate, before it's actually gone.

## SLOs on checks and dependencies

Define SLOs on HTTP check success rate, browser check success rate, and response time percentiles. And uniquely: define SLOs on third-party domains detected in browser checks.

Track whether your CDN, analytics provider, or tag manager is meeting your own internal SLO, because their degradation directly impacts your product's measured performance.

| SLI type | Example target |
| --- | --- |
| HTTP success rate | 99.5% / 30-day window |
| Browser success rate | 99.9% / 30-day window |
| p95 response time | < 500ms / 30-day window |
| Web Vitals (LCP) | < 2.5s / 30-day window |
| Third-party domain | cdn.example.com success rate |

### Third-party SLO: cdn.tagmanager.net

- **SLI:** request success rate
- **Target:** 99.0% / 30-day window
- **Current:** 97.4%, budget exhausted in 2d

Detected automatically from browser check request analysis, with no manual configuration for the third-party endpoint.

## Burn rate alerting

Alert when the error budget will be exhausted at the current rate, before it's actually exhausted. Configure burn rate multiplier thresholds for fast burn (immediate alert), medium burn (paging), and slow burn (warning).

A 4x burn rate on a 99.9% SLO means your budget will be gone in 7.5 days instead of 30. You want to know now, not when users are already affected.

### Burn rate alert thresholds

| Threshold | Burn rate | What it means | Severity |
| --- | --- | --- | --- |
| Fast burn (1h window) | 14.4x burn rate | Budget exhausted in < 1h at this rate | Critical |
| Medium burn (6h window) | 6x burn rate | Budget exhausted in < 6h at this rate | Warning |
| Slow burn (3d window) | 3x burn rate | Budget exhausted within the window | Info |

## Synthetic SLIs in your OTel stack

Current availability, budget remaining, and 1h/6h/24h burn rates emitted on every SLO budget warning event. Include synthetic SLIs in your existing SLO dashboards alongside backend SLIs, not in a separate monitoring dashboard.

The metrics emitted:

```
synthetics.slo.target
synthetics.slo.availability.current
synthetics.slo.budget.remaining_pct
synthetics.slo.burn_rate.1h
synthetics.slo.burn_rate.6h
synthetics.slo.burn_rate.24h
```

### Attributes on every synthetics.slo.budget.warning event

| Attribute | Value |
| --- | --- |
| `synthetics.slo.target` | 0.999 |
| `synthetics.slo.availability.current` | 0.9972 |
| `synthetics.slo.budget.remaining_pct` | 28 |
| `synthetics.slo.burn_rate.1h` | 4.2 |
| `synthetics.slo.burn_rate.6h` | 2.8 |
| `synthetics.slo.burn_rate.24h` | 1.4 |

## Unlike SLOs bolted onto a monitoring dashboard

- Most synthetic monitoring tools have SLO features that live in a separate dashboard. Yorker emits SLO context as attributes on synthetics.slo.budget.warning log events, so they land in the same backend as your infrastructure SLOs, queryable in the same dashboards.
- Third-party SLOs are unique to Yorker. Define an error budget on a CDN or analytics provider and know when their degradation is burning through your budget, without adding a separate monitoring tool.
- Burn rate alerting means you get notified when the budget is burning too fast, not when it's already gone and your users are already affected.

## Related features

- **[Alerting](/features/alerting):** Burn rate alerts integrated with multi-location correlation.
- **[Browser Monitoring](/features/browser-monitoring):** Browser check SLOs and third-party dependency error budgets.
- **[API Monitoring](/features/api-monitoring):** HTTP check success rate and response time SLOs.

## Put your first check live in one command.

Free tier includes 10,000 HTTP + MCP checks and 1,500 browser checks per month. No credit card required.

[Start Free](/sign-up) · [Read Docs](/docs)

```
npx @yorker/cli init
```