A number the board understands.
A page before the budget is gone.
Datadog Service Level Objectives turn the metrics and monitors you already have into a target, an error budget and a burn rate that pages while there is still something to save. We implement them on the services that carry a promise and set the targets the service can actually meet. We run them every month so the report the board reads is the same one the on-call engineer trusts.
Quick facts
Related
- Incident Management, what the incident cost in error budget
- Alerts, the monitors the SLOs are built from
- APM, the latency and error metrics most SLOs measure
One number per service that engineering and the board can both argue about honestly
The contract says ninety-nine point nine. The dashboard says green. The support queue says Tuesday was bad. An SLO is the one number that reconciles them: a target, measured from real traffic, with a budget for the bad minutes. The alert fires on how fast the budget is going, not on whether it has gone.
A type for each kind of promise. A metric-based SLO for a rate: good requests over all requests. A monitor-based SLO for an uptime measured by an existing monitor. A time slice SLO for an uptime defined by a condition on a metric, in one-minute or five-minute slices, with no monitor to maintain.
An error budget, which is what the target really means. Ninety-nine point nine over thirty days is about forty-three minutes of bad time. The budget is what is left of that, and remaining budget is a better planning number than the status.
Alerts on speed, not on the total. Burn rate alerts fire when the budget is being spent faster than a threshold, over a long window confirmed by a short one. A fast outage pages in minutes. A slow leak pages in hours. Both before the month is lost.
The report, on a schedule, to the right people. SLO widgets and the SLO List on a dashboard, sent as a scheduled PDF to email, Slack or Teams, with twelve months of calendar history behind it. The board gets the number without asking an engineer for it.
A target the dependency cannot meet, a monitor that is also the SLO, and a maintenance window reported as an outage
How it bills. There is no SLO meter. Datadog's price list carries no SLO line, and Datadog lists SLOs among the platform's built-in capabilities. SLO alerts are monitors, and alerts are unlimited on every Infrastructure plan. The cost sits underneath. A metric-based SLO on a business event usually needs a custom metric, which counts against the custom metric allotment. A monitor-based SLO needs the monitor's product, such as APM or Synthetic Monitoring, to be on. Datadog publishes the rates. The configuration that decides the number is the metric behind the SLO, and we check its cardinality before the SLO exists.
The configuration traps. A target of four nines on a service whose database promises three, so the budget is gone by the second day of every month and the alerts are muted by the third. The paging monitor used as the SLO monitor, so every threshold change to stop a noisy page silently loosens the promise. No status corrections, so every maintenance window is an outage in the report and the report is not believed. A time slice SLO grouped by a tag, so one tiny group with a flaky endpoint drags the whole service to red. A target of a hundred per cent, which has no budget and breaks the alert maths.
Field noteThe most common gap we see is the target chosen from the contract rather than from the service. The contract says four nines. The dependency underneath offers three. The SLO is red from the first week and is read as a tooling problem rather than an architecture one.
Field noteThe monitor that pages the on-call is also the monitor behind the SLO. Its threshold is relaxed to stop the pages, which is a reasonable thing to do to a pager, and the SLO quietly reports a better month than the customers had.
Field noteThe pattern we keep finding is the maintenance window with no correction. The platform is patched every other Sunday, each patch is a few minutes of downtime, and by month end the SLO shows a breach that was entirely planned. The report is dismissed, and with it the real breach in week three.
Field noteSLOs created for the board and never given an alert. The dashboard shows the status and nobody is paged on the burn. The first anyone hears that the budget is gone is the monthly report, which is the one place the news is no longer useful.
The promise first. The target from the data. The alert before the dashboard.
When the services and their targets are not yet agreed, SLOs are set up inside LaunchPad, because the conversation about what is being promised needs a project around it. When SLOs already exist and nobody trusts them, a Datadog HealthScan reports their targets, their metrics and their alert coverage first, read-only and fully automated. The sequence is the same either way.
- Name the promises. Which services carry a commitment, to whom, and in what terms: availability, latency, freshness. A service with no promise does not get an SLO, it gets a monitor.
- Choose the type per promise. Metric-based for a rate. Time slice for an uptime defined on a metric. Monitor-based only where a monitor already captures the promise exactly, and never the paging monitor.
- Set the target from a month of data. What the service actually achieved, what its dependencies offer, and what the contract says, in that order. A target the service cannot meet is a target that will be muted.
- Build the burn rate alerts. Two or three per SLO at different speeds, with long and short windows from Datadog's recommended table for the target. The fast one pages. The slow one goes to the team channel.
- Set the corrections. Recurring status corrections for the maintenance calendar, categorised, plus one-off corrections from monitor downtimes, so the report tells the truth about the service.
- Build the report and hand over, in writing. SLO widgets and the SLO List on a dashboard, scheduled to the people who asked for the number. The handover lists each SLO, its type, its target and why, its alerts and its corrections.
Access is admin on the Datadog organisation with the SLO write and correction permissions, and a view of your maintenance calendar. The targets are yours to set. We will say when the data disagrees with the contract, and we will say it before the SLO is created rather than after it is red.
An SLO nobody reviews becomes a number nobody believes
A dependency is replaced and the service can now do better. A new service ships with a contract and no SLO. A correction is added for one maintenance window and reused for an outage. Managed Observability keeps the targets, the alerts and the corrections honest every month. Critical Support answers the burn rate page.
Every month, status and budget are reviewed. Each SLO's remaining budget, whether its burn rate alerts fired for real reasons, and whether the target still matches what the service and its dependencies can do. A target that is always met or never met gets revisited.
Coverage follows the promises. A new service with a commitment and no SLO is found in the review and given one. A retired service's SLO is removed from the report rather than left reporting on nothing.
Corrections are kept honest. Every correction is checked against what was actually maintenance. An outage recorded as a correction is reversed, with the reason, because a report that flatters the service is worse than no report.
The burn rate page is ours to take. Under Critical Support our engineers answer the fast burn alert, 24x7, and fix the cause rather than report it. The budget spent during the incident appears in the report with the cause attached. Datadog has published that our work reduces mean time to resolve incidents by 40 to 60 per cent.
We operate the stack. You own the product.
An SLO is a promise with a measurement attached, and we are the people who get paged when the measurement moves. That changes how we set them. We will not create a target the service cannot meet, because we would be the ones muting it in week two. We will not use the paging monitor as the SLO monitor, because we tune pagers. The SLOs, the alerts and the report stay in your Datadog organisation, documented, and the targets stay yours to set.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Service Level Objectives, answered plainly
What types of SLO does Datadog support?
Three. A metric-based SLO counts events: good requests divided by total requests, from any metric. A monitor-based SLO measures time: the proportion of the window in which a Datadog monitor was not in alert. A time slice SLO also measures time, but from a condition on a metric evaluated in one-minute or five-minute slices, with no monitor needed and missing data counted as uptime. Each takes a target below a hundred per cent and a rolling window of seven, thirty or ninety days. Which type fits depends on whether the thing being promised is a rate or an uptime, and we choose per service rather than per habit.
How are Datadog SLOs billed?
There is no SLO meter. Datadog's price list carries no SLO line, and Datadog lists SLOs among the platform's built-in capabilities. SLO alerts are monitors, and alerts are unlimited on every Infrastructure plan. What costs is underneath. A metric-based SLO on a business event usually needs a custom metric, which counts against the custom metric allotment. A monitor-based SLO needs the monitor's product, such as APM or Synthetic Monitoring, to be on. Datadog publishes the rates. We do not publish prices. We check the metric behind each SLO before it is created, so a service level does not quietly become a cardinality bill.
What is a burn rate alert and why not just alert on the SLO?
An error budget alert fires when a set share of the budget has been used. By then the month may be lost. A burn rate alert fires when the budget is being consumed faster than a threshold, sustained over a long window and confirmed by a short one. A fast outage pages in minutes and a slow leak pages in hours. Datadog sets the short window at a twelfth of the long one, following Google's guidance, and blocks thresholds that exceed the maximum possible for the target. We set two or three burn rate alerts per SLO, at different speeds, and route the fast one to the pager and the slow one to the team channel.
How do planned maintenance windows affect our Datadog SLOs?
Without a status correction, a maintenance window is an outage in the report. Datadog's SLO status corrections exclude a period from the calculation, one-off or recurring, tagged by category such as scheduled maintenance, deployment or outside business hours. A metric-based SLO drops the events in the window, a time slice SLO counts it as uptime, and a monitor-based SLO ignores it. The consequence is that monitor-based corrections shorten the window the budget is measured over. We set up recurring corrections for the maintenance calendar at implementation and create one-off corrections from monitor downtimes, so the report tells the truth about the service rather than about the change calendar.
What does Critical Cloud do with Service Level Objectives every month?
Managed Observability reviews every SLO's status and remaining budget each month. It checks that the targets are still ones the service can meet, that the burn rate alerts fired for real reasons, and that the corrections match what was actually maintenance. It adds SLOs for services that shipped without one and sends the scheduled report. Under Critical Support our engineers answer the burn rate page itself, 24x7, and the error budget spent during the incident is in the report with the cause.
- Datadog products: every product, and how we implement and run each one
- Incident Management and Alerts: the incident that spends the budget, and the monitors the SLOs are built from
- APM: the latency and error metrics most SLOs are measured on
- LaunchPad: the project-managed rollout where the promises, the targets and the report are agreed
A target the service can meet. A page before the budget is gone.
Tell us which services carry a promise and what the contract says. We will tell you what the data says they can meet, which SLO type fits each one, and what it takes to have the report believed.