Advanced SLO CalculatorComposite mode
Enterprise-grade SLO planning with availability or latency SLIs, evaluation periods, baseline adjustment, and recommended multi-window burn alerts.
Composite SLO
99.96%
Error budget (events)
400
Error budget %
0.040%
Allowed downtime (min/period)
17.28
Downtime (hrs/yr)
3.50
On-call burden
Medium
Error Budget Over Time
Cumulative allowed budget (upper bound) across the selected period and the constant daily allowance.
Recommended Multi‑Window Burn Alerts
Use fast + slow windows to catch both sharp regressions and smoldering issues.
| Window (hrs) | Burn rate | Budget consumed |
|---|---|---|
| 1 | 14.4× | 0% |
| 6 | 6× | 0% |
| 24 | 3× | 0% |
| 72 | 1× | 0% |
Per‑endpoint Split
Allocate error budget between critical and non‑critical endpoints.
Critical endpoints (60%)
240 events
Non‑critical endpoints (40%)
160 events
Exports
How to use this calculator
Quick start
- Choose an evaluation period that matches how you operate (7/30/90/365 days).
- Enter total events in period (requests/transactions).
- Set business criticality and optional baseline good ratio (historical success).
- Toggle Composite mode to combine availability + latency; tune method and weights.
Composite mode
- Uses both availability and latency. The “SLI type” control is disabled while composite is on.
- Min method takes the stricter of the two SLOs; Weighted averages by your weights.
- Latency settings (threshold & percentile) are always active in composite.
Inputs
- Service type adjusts recommended SLO bands and on‑call burden.
- Existing uptime seeds target realism; baseline good ratio nudges the recommendation.
- Latency: set a user‑meaningful threshold (e.g., 200ms) and percentile (p95/p99).
- Per‑endpoint split allocates error budget between critical and non‑critical endpoints.
Outputs & alerts
- Recommended SLO / Composite SLO and error budget (events & %).
- Allowed downtime for the selected period and estimated on‑call burden.
- Chart: cumulative allowed budget and steady daily allowance.
- Burn alerts: multi‑window pairs catch both spikes (1h) and slow burns (24–72h).
- Exports: JSON (inputs + results), CSV (alert table), YAML (Alertmanager rules).
Why this is helpful
- Right‑sized targets that balance user expectations with sustainable on‑call.
- Faster alerting setup with opinionated, production‑tested burn‑rate windows.
- Decision support via baseline adjustment, composite SLIs, and per‑endpoint budgeting.
