SLOs on your synthetic monitorsIncluding 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.
How it works
Define the SLI
Choose success rate, response time percentile, or Web Vitals threshold as your SLI. Attach it to any HTTP or browser check.
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.
Monitor tracks actual vs target
The SLO dashboard shows current SLI value, budget consumed, and burn rate — updated on every check run.
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.
HTTP success rate99.5% / 30-day windowBrowser success rate99.9% / 30-day windowp95 response time< 500ms / 30-day windowWeb Vitals (LCP)< 2.5s / 30-day windowThird-party domaincdn.example.com success rate14.4× burn rateBudget exhausted in < 1h at this rate
6× burn rateBudget exhausted in < 6h at this rate
3× burn rateBudget exhausted within the window
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 4× 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.
Synthetic SLIs in your OTel stack
SLO status, current SLI value, and burn rate emitted as OTel metrics on every check run. Include synthetic SLIs in your existing SLO dashboards alongside backend SLIs — not in a separate monitoring dashboard.
synthetics.slo.budget_remainingsynthetics.slo.burn_ratesynthetics.slo.sli_valuesynthetics.slo.targetsynthetics.slo.statussynthetics.slo.sli_value0.9972synthetics.slo.target0.999synthetics.slo.budget_remaining0.28synthetics.slo.burn_rate4.2synthetics.slo.statusat_risksynthetics.slo.window_days30Unlike SLOs bolted onto a monitoring dashboard
Most synthetic monitoring tools have SLO features that live in a separate dashboard. Yorker emits SLO metrics as OTel signals — 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.
Close your observability blind spot
Free tier includes 10,000 HTTP checks and 1,500 browser checks per month. No credit card required.
npx yorker init