SLOs and on-call
Know when the error budget burns, and who answers
Set availability and latency objectives on the traces or logs you already send, and every SLO gets its own burn-rate monitor. On-call schedules and escalation policies carry its pages to the right team until someone acknowledges.
- 7, 30 or 90 days
- 14.4× · 6× burn alerts
- 5-step escalation
How it works
From an objective to an acknowledged page
The SLO, its burn-rate monitor and the escalation behind it form one chain, from the first minute of burn to the person who acknowledges the page.
- 01DefinePick traces or logs, availability or latency, a service, a target and a 7, 30 or 90-day window.
- 02MeasureGood and total events roll up every minute; each SLO shows its budget and its burn over 1 and 6 hours.
- 03AlertIts burn-rate monitor goes critical at 14.4× and warns at 6×, over the last hour and 5 minutes.
- 04PageA notification policy with an escalation policy opens a page for the on-call schedule's team.
- 05EscalateAn unacknowledged page moves to the next step after the wait you set, up to five steps.
- 06ResolveAcknowledging stops escalation, and the page resolves on its own when the alert recovers.
SLOs
Objectives on the data you already send
An SLO counts good and total events: spans without errors or under a latency threshold, or log lines below error. It rolls them up every minute, and the error budget and burn rates follow from the target you set.
- Scope an SLO to one service, environment or service group, or leave it open
- Minutes with no events are left out of the SLI instead of counting as good
- A deploy fails its post-release check when its service burns an SLO faster than 6× over an hour
Escalation
Pages climb the policy until someone acknowledges
Each escalation step names the schedules, teams or channels to page, and how long to wait for an acknowledgement before it moves on. Acknowledge the page and the climb stops.
Rotations
Members hand off every 1 to 90 days, weekly unless you choose otherwise.
Overrides
Take over a shift in one click; the latest override always wins.
Up to five steps
Each step waits from 1 minute to 24 hours, 15 minutes by default.
Named in every page
Pages go to the team's channels and say who is on call.
On-call
Who is on call now, and what paged them
The On-call page shows every schedule with the person on call and when their shift ends, the escalation policies in use, and the pages of the last seven days with who acknowledged each one.
- Take over the current shift in one click when you swap with a colleague
- Every page keeps its step, its acknowledger and when it resolved
- Ask Brain who is on call at any moment, or to acknowledge a page for you
Pages · last 7 days
Better together
Reliability goals tied to the signals behind them
SLOs read the same spans and logs as the rest of your workspace, so a burning budget leads straight to the traces and the problem behind it.
- APM and distributed tracingSLOs read the same spans as your service map and traces, scoped by environment and service group.Learn more
- Monitors and alertingNotification policies decide which alerts page on-call, and where everything else goes.Learn more
- Problems and casesWhen a page fires, the problem behind it already holds the related alerts and recent changes.Learn more
Does Tracix call or text the person on call?
Can we import schedules from PagerDuty or Opsgenie?
How does missing data affect the error budget?
Can a schedule have several layers or shorter shifts?
Set your first SLO
Pick a service you already trace, choose a target and a window, and its burn-rate monitor is created with it.