SLO Monitors
Set a reliability target, such as 99.9% of checkout requests succeeding over 30 days, and be alerted when it's at risk rather than on every blip.
An SLO (service level objective) says how reliable something should be: a share of good events over a rolling window. The share that may fail is the error budget. At 99.9%, 1 request in 1,000 may fail; for uptime, that is about 43 minutes of downtime every 30 days. An SLO monitor measures data Zharp already has, so it has no regions and probes nothing.
Set one up
- 1Pick the type
In Create monitor, open Monitor type and choose SLO monitor, under Application & APIs.
- 2Choose what counts as good
What counts as good Good Measured from Requests succeed A request that didn't fail The traces your application sends: each request's entry span Requests are fast A request that answered within the time you set The same traces Monitors are up A check that passed The monitors you pick; paused and maintenance time don't count For requests, pick the service, and optionally only some of its operations, such as POST /checkout.
- 3Set the target and window
The target is a percentage (99.9% by default) over a rolling 7, 28 or 30 days. The form says what budget that leaves.
When it alerts
SLO monitors alert on the burn rate: how fast the budget is being used. At 1×, it would run out exactly at the end of the window. Zharp uses the multi-window rules from Google's SRE workbook:
| Rule | Fires when, for a 30-day SLO | What happens |
|---|---|---|
| Fast burn | 14.4× over the last hour and the last 5 minutes (2% of the budget in an hour) | The monitor goes down and alerts |
| Steady burn | 6× over the last 6 hours and the last 30 minutes (5% in 6 hours) | The monitor goes down and alerts |
| Slow burn | 1× over the last 3 days and the last 6 hours (on course to run out) | Shown on the monitor; alerts only with Also alert on a slow burn under Advanced settings |
- Both windows must burn that fast, so a spike that has already stopped doesn't alert, and the monitor comes back up soon after things recover.
- Fewer than 10 events in the short window never alerts, so one failure at 3 a.m. can't page anyone.
- For 7 and 28-day SLOs the rates are scaled so they mean the same share of the budget.
- Alerts go through the monitor's incident like any other: on-call, escalation, channels and maintenance windows all apply.
The monitor's page
It shows the value over the window, the budget left, how the budget burned down day by day, the burn rate for each rule, and, for request SLOs, the operations that used the budget, each with its latest failing trace.
A new SLO counts back over its window from the data Zharp still has, and keeps its own per-minute counts for 400 days whatever your plan keeps of the traces. Measuring since says when its count starts. Changing what it measures starts a fresh count; changing the target or window doesn't.