Datadog · SLO monitoring
SLO monitoring: turning SLAs into objectives, error budgets and a report management can read
SLO monitoring measures each important service against a target agreed in advance, every minute instead of at month end. It turns the promise the business has made, an SLA in a contract or a level management expects, into an indicator measured from what users experience, an objective and an error budget. This guide covers that translation, alerting before the budget is gone, reporting to management, and where Datadog fits for teams in Saudi Arabia.
Published 9 min read
Orientation
At a glance
The whole page in one table, before the detail.
- What it is
- Measuring services all the time against agreed objectives, each with an error budget
- What it starts from
- A business promise: an SLA in a contract, or the service level management expects
- What it produces
- Status and budget left per service, early alerts and a periodic report
- In Datadog
- Service Level Objectives over 7, 30 or 90 days, built on metrics or monitors you already send
- Saudi angle
- Several suppliers, bilingual reporting, telemetry stored outside the Kingdom
The problem in plain words
- The usual situation: a contract or a management target names a service level, and the only way to know whether it was met is a spreadsheet built after the month has ended.
- What SLO monitoring changes: the target is measured all the time, from what users experience, so the team sees a missed month coming days ahead.
- The real work: not the tool but the translation. Each SLA clause has to become an indicator, an objective and an error budget that the business and the engineers both accept.
- The output for management: one page per period: each service, its target, where it stands, how much budget is left and what the team did about it.
SLO monitoring: from a contract figure to a number engineers watch
A service level indicator (SLI) measures how the service behaves for users, such as the share of payment requests that succeed. A service level objective (SLO) is the target for it over a window, such as 999 in every 1,000 over 30 days. A service level agreement (SLA) is a promise in a contract, with a consequence if it is missed. Our entry What is SRE explains the terms.
Read more
SLA monitoring looks backwards at whether last month's promise was kept; SLO monitoring looks forwards. The SLO is set tighter than the SLA, so the warning comes while there is time to act, and the error budget, the failure the objective allows, shows how much room is left: at 999 in 1,000, one request in 1,000 may fail. While budget remains, releases go ahead; when it runs low, the team slows change and fixes what is fragile.
Measure where the user is. A server that is up while the login page fails is not a working service, so indicators come from request outcomes, response times and synthetic tests of real journeys, not host uptime alone.
Why service level objectives matter for teams in Saudi Arabia
Digital services in the Kingdom are often run by several parties at once: an in-house team, a managed service provider, a cloud platform and a software supplier, each with its own contract and report. When a citizen portal or a banking app is slow, every report can show green while users complain. Service level objectives give all of them one measure taken from the user's side. Management, too, asks how reliable the main digital channels were this quarter, and needs one answer in Arabic and English that does not depend on who prepared it.
Read more
Two practical points come up early. First, the telemetry behind an SLO goes to wherever your monitoring platform stores it. Datadog is a SaaS platform, and as of November 2026 none of its sites is in the Middle East, so decide which data may leave your network and mask personal fields before they are sent; our Datadog data residency guide sets out the options. Second, each SLO needs a named owner, or nobody reviews it.
RelatedDatadog data residency guide
From SLA to SLO: turning business promises into measurable objectives
Illustrative wording and figures over a 30-day window; yours will differ.
| What the business promised | SLI (what to measure) | SLO (the target) | Error budget for 30 days | Note |
|---|---|---|---|---|
| Customers can pay online at any time | Share of payment API requests that succeed | 999 in 1,000 over 30 days | 10,000 failed requests out of 10 million expected | Count requests when traffic is high and steady |
| The portal is available, with a monthly availability figure in the contract | Minutes in which a synthetic login test passes | 999 in 1,000 minutes over 30 days | 43.2 minutes in which the test may fail | Set tighter than the contract figure, so the warning comes first |
| Pages respond quickly | Share of requests answered in under 300 ms | 99 in 100 over 30 days | 1 slow request in every 100 | Agree the threshold, then measure it for a few weeks |
| The supplier responds to a critical ticket within an agreed time | Not a user-facing SLI | Not an SLO | None | Ticket response belongs to the service desk report, not to SLO monitoring |
Many SLA clauses describe ticket handling, not how the service behaves for users; keep those in the service desk report. For the user-facing rows, the data usually comes from website monitoring and synthetic tests for availability, and from Datadog APM for request success and response times.
Error budget and burn rate alerts: SLA monitoring that warns early
An SLO read only at month end is a report, not monitoring. Datadog documents two kinds of alert that act in time.
- Error budget alerts fire when a set share of the budget for the window has been consumed, with an optional earlier warning.
- Burn rate alerts watch how fast the budget is being spent. A burn rate of 1 spends the budget exactly over the window; 10 spends it ten times as fast. A long window, from one to 48 hours, confirms the problem is real, and a short window lets the alert clear once it ends. For a 30-day SLO, Datadog's own suggested starting points are a burn rate of 14.4 over one hour, 6 over six hours and 3 over 24 hours, each with a short window of one twelfth of the long one.
Read more
Fast burn pages the on-call engineer; slow burn opens a ticket. When users are affected now, the alert should start the incident process; our Datadog incident management page covers on-call, severities and the incident timeline.
If the contract excludes agreed maintenance windows, Datadog's status corrections, one-off or recurring, remove those periods from the SLO status and error budget, and are recorded with the SLO.
Ways to measure an SLO: the options and their trade-offs
Where many start, then the three SLO types Datadog documents.
| Option | How it works | Good for | Watch out for |
|---|---|---|---|
| Monthly report built by hand | Uptime figures and tickets put in a spreadsheet after month end | A contract's reporting duty, with no new tooling | Too late to act on; the figure depends on who built it |
| Metric-based SLO | Good events divided by total events, from request counts | High-traffic APIs and journeys | Needs clean success and total counts |
| Monitor-based SLO | The time an existing Datadog monitor is healthy | Availability built on a health check or synthetic test | Noisy monitors make noisy SLOs |
| Time slice SLO | Each minute is good or bad by a condition you define; no monitor needed | Uptime-style targets, such as minutes under a response-time threshold | Choose the condition carefully |
Each Datadog SLO uses a rolling window of 7, 30 or 90 days; 30 days usually matches the monthly rhythm of contracts and reports. An SLO can be split by group, such as region, with status and budget left shown per group.
Reporting service levels to management
Management does not need burn rates. It needs, per service, five things: the objective in plain words, the result for the period, the error budget left, the trend, and one line on what the team changed.
In Datadog an SLO widget shows one objective; an SLO List widget shows a set, filtered by tags such as team; the SLO data source graphs up to 15 months of metric-based SLO history; and the calendar view shows up to 12 months of status for metric-based and time slice SLOs. Datadog's scheduled reports then email that dashboard as a PDF on a recurring schedule, with nobody preparing it by hand.
Report against the SLO the business agreed, not one changed during the period, and show excluded maintenance windows. We write each objective in Arabic and English side by side.
Before you set service level objectives: a checklist
Questions to settle with each service owner before the first SLO goes live.
| Question | Why it matters |
|---|---|
| Which promise, in which contract or plan, does this SLO support? | An SLO with no business promise behind it is rarely reviewed |
| Is the SLI measured from the user's side? | Host uptime can be green while users cannot log in |
| Is the SLO tighter than the SLA? | Otherwise the warning arrives when the contract is already missed |
| What happens when the error budget runs low? | Agree the response with the business before it is needed |
| Which maintenance windows are excluded, and who records them? | Exclusions must be visible to both sides of the contract |
| Who receives the report, in which language, how often? | The report is what management sees of the whole effort |
Where Datadog SLOs fit, and where they do not
Datadog SLOs fit when the data behind the indicator is in Datadog, or can be: APM, synthetic tests, real user monitoring, infrastructure metrics. Objective, alerts, incidents and the management dashboard then share one platform.
Where it may not fit: if personal data must never leave the Kingdom and cannot be masked reliably, a SaaS platform with no Middle East site is a constraint to settle first. If a contract names a specific measurement source, the contract's source decides the SLA result; your SLO is your own early warning, not evidence the other party has agreed to accept, unless the contract says so. We will tell you which applies before you buy.
SLOs are built on monitors and metrics you already send, so their cost follows those products; see our Datadog pricing guide.
How Interkey sets up SLO monitoring
-
Read the promises.
Contract SLAs and management targets.
-
Translate them.
For each clause, an SLI, an SLO and an error budget, or a note that it belongs elsewhere.
-
Check the data.
What exists, what is missing, what must be masked.
-
Build the SLOs and alerts.
SLO types, budget and burn rate alerts, maintenance corrections.
-
Connect the response.
Paging and tickets to the owning team.
-
Build the management report.
A dashboard and a scheduled report in Arabic and English, reviewed with you after the first full window.
-
Operate or hand over.
Interkey, an official Datadog partner in Saudi Arabia, sells the licences, implements and supports them from Riyadh, or hands over with documentation.
Questions buyers ask about SLO monitoring
What is the difference between SLA monitoring and SLO monitoring?
SLA monitoring checks after the period whether a contract promise was kept. SLO monitoring measures a tighter internal target all the time and tracks the error budget, so the team is warned while there is still time to act.
Can we use SLOs to hold our IT suppliers in Saudi Arabia to their SLAs?
Yes, if the contract agrees the measure. If it names a different source, that source decides the SLA result, and your SLOs remain your early warning.
How do we stop planned maintenance from using up the error budget?
Record the agreed maintenance windows as status corrections in Datadog, one-off or recurring. They are removed from the SLO status and error budget, and the report shows what was excluded.
Do Datadog SLOs cost extra on top of our monitoring licences?
SLOs are built on the monitors and metrics you already send, so their cost follows the monitoring products underneath. Interkey quotes Datadog licences in Saudi Arabia together with set-up and technical support.
Is the data behind our SLOs kept inside the Kingdom?
No. The telemetry an SLO is measured from is stored on your Datadog site, and as of November 2026 none is in the Middle East. Decide what may leave your network and mask personal fields before they are sent.
How long does it take to set up SLO monitoring and a first management report?
There is no fixed figure: it depends on the number of services, existing monitoring and how fast owners agree targets. A meaningful report needs one full window of data. We estimate after reading your SLAs.
Next
Read next
Next step
Turn your SLAs into SLOs
Tell us which services carry a contract SLA or a management target, how you report on them today, and what monitoring runs. We reply with first SLOs, alerts and a report outline, and quote Datadog if it fits.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia