Glossary
What is SRE? Site reliability engineering explained
What is SRE? Site reliability engineering (SRE) is a way of running software services in which engineers treat reliability as a measurable feature: they agree how reliable each service needs to be, measure it from what users experience, and use the gap between the target and perfection, the error budget, to decide when to ship new features and when to fix what is fragile. SRE is both a set of practices and, in many organisations, the name of the team that applies them.
Glossary Published 7 min read
In short
- SRE meaning: site reliability engineering, applying software engineering to operations work so that services stay reliable as they grow.
- The core idea: no service needs to be perfectly reliable. Agree a target, measure it, and spend the remainder deliberately.
- The vocabulary: SLI (what you measure), SLO (the target you set), SLA (the promise in a contract) and error budget (the failure you can afford).
- What it is not: a tool you buy. Tools record and alert; the practice is the agreements a team keeps.
Definition
What is SRE, in plain terms
Every online service fails sometimes. Operations teams resist change because change causes failure; product teams want to change things quickly. Site reliability engineering settles that argument with numbers instead of opinions.
The practice began at Google in the early 2000s, and Google has since published its approach openly on its SRE site and books. The ideas travel well beyond large technology companies. An SRE team, or a platform team working this way, typically:
Read more
- defines a small number of measures that reflect what users feel, such as failed requests or slow pages;
- sets a target for each and reviews it with the service owner and the business;
- automates repetitive operational work, which SRE calls toil, so engineers have time for lasting fixes;
- runs incidents with clear roles and writes a blameless review afterwards;
- keeps alerts few and meaningful, so a page at night always means something.
Relatedits SRE site and books
SLI, SLO and SLA
SLI, SLO and SLA: the three terms SRE is built on
| Term | Stands for | What it is | Example | Who owns it |
|---|---|---|---|---|
| SLI | Service level indicator | A measurement of how the service behaves for users | Share of checkout requests that succeed | The engineering team |
| SLO | Service level objective | The target for an SLI over a time window | 999 of every 1,000 checkout requests succeed over 30 days | The service owner, agreed with the business |
| SLA | Service level agreement | A promise in a contract, with a consequence if it is missed | A monthly availability figure in the contract, with a service credit if it is missed | The commercial and legal teams |
An SLO is usually set tighter than the SLA, so the team sees trouble and reacts before the contract is at risk. Many internal services have SLOs and no SLA at all.
Error budget
What an error budget is, and how teams use it
The error budget is the amount of failure an SLO allows. If the target is 999 successful requests in every 1,000 (often written as 99.9 per cent, or three nines), the budget is the one request in 1,000 that may fail. While budget remains, the team ships features at its normal pace. When the budget is close to spent, the agreed response is to slow releases and put the effort into reliability until the service is back within target. That agreement turns "should we release on Thursday?" into a reading of one number everyone accepted in advance.
Worked example
Error budget worked example
Illustrative figures for one service over a 30-day window, 20 days in.
| SLI | SLO | Error budget for 30 days | Used after 20 days | Budget left | What the team does |
|---|---|---|---|---|---|
| Successful requests (10 million expected) | 999 in 1,000 | 10,000 failed requests | 4,000 failed | 6,000 requests | Releases continue as planned |
| Requests answered in under 300 ms | 99 in 100 | 100,000 slow requests | 85,000 slow | 15,000 requests | Slows releases and works on the slow endpoint |
| Minutes the health check passes (43,200 in 30 days) | 999 in 1,000 | 43.2 minutes of downtime | 30 minutes | 13.2 minutes | Reviews the two outages before the next risky change |
The latency budget is burning faster than the calendar: two thirds of the window has passed but 85,000 of its 100,000 slow requests are already used. SRE teams alert on this burn rate, because it warns of a missed SLO days ahead.
Compared
SRE vs DevOps: how they relate
| DevOps | SRE | |
|---|---|---|
| What it is | A culture and set of practices that bring development and operations together | A specific way of putting those practices to work, with reliability targets |
| Main focus | Delivering change quickly and safely | Keeping services within agreed reliability while change continues |
| Typical measures | Deployment frequency, lead time, change failure rate, time to restore | SLIs, SLOs, error budget, toil, MTTR |
| Typical people | Developers and operations engineers sharing ownership | Engineers with software skills who own production reliability |
They are not rivals: DevOps describes what a team believes, SRE is one concrete way of doing it. Many teams in the Kingdom adopt SRE practices one service at a time, without renaming anybody.
Tooling
The tools an SRE team needs
SRE is a practice, but it cannot run on guesswork. Four kinds of tooling come up in almost every team:
- Monitoring and alerting: metrics, logs and health checks for every service, with alerts that fire on what users feel and reach the owning team.
- Distributed tracing: following one request across services, so the cause of a slow or failed call is found quickly.
- Incident management and on-call: paging the right person, declaring an incident with a severity and a lead, keeping a timeline, and writing the review. The MTTR glossary entry explains how this shortens recovery time.
- SLO tracking: SLOs defined on the same data as the alerts, with the error budget left and an alert when it burns too fast.
When these live in separate products, the error budget is often worked out by hand at month end, too late to act on.
Datadog and Interkey
How Datadog covers SRE tooling, and where Interkey helps
Datadog puts the four kinds of tooling on one platform. Monitors alert on metrics, logs and traces; Datadog APM traces requests across services; Datadog SLOs set targets over 7, 30 or 90 days on monitors or metrics you already send and show the error budget left; and Datadog documents that incidents can be declared from monitor alerts, with a severity, an incident commander and responder roles, and postmortems drafted in Notebooks. Datadog On-Call handles paging. These are Datadog's own descriptions of its products.
Read more
Interkey sells Datadog licences in Saudi Arabia, implements the platform and provides technical support from Riyadh. For an SRE programme that usually means choosing the first SLIs with each service owner, setting up SLO monitoring and burn-rate alerts, cleaning up the alerts the on-call team no longer trusts, and configuring Datadog Incident Management so reviews are written the same way every time.
In a Saudi context
SRE in a Saudi context
Platforms in the Kingdom often span data-centre systems, cloud services and several suppliers. SLOs give those parties one shared language: a supplier can be held to the SLI that users feel, not only to a server uptime figure. Telemetry also raises a residency question. Datadog is a SaaS platform, and as of November 2026 Datadog lists no site in the Middle East, so decide which data may leave your network and mask personal fields before they are sent. Interkey's engineers work with your team in Arabic and English.
Questions teams ask about SRE
Is SRE a job title or a way of working?
Both. Some organisations hire site reliability engineers into a dedicated team; others ask existing platform or operations engineers to adopt SLOs, error budgets and blameless reviews.
Do we need a separate SRE team to start with SRE practices in Saudi Arabia?
No. Most teams in the Kingdom start with one important service: agree two or three SLIs with its owner, set an SLO, and review the error budget each week. A dedicated team makes sense later, once several services work this way and the reviews need an owner.
How do we pick the first SLO target for a service?
Start from what users already experience. Measure the SLI for a few weeks, set the SLO slightly below what you achieve today, and tighten it only when users or the business need more.
What happens when a service runs out of error budget?
Whatever the team agreed in advance. The usual policy is to pause risky releases and spend engineering time on reliability until the service is back within its SLO. Agree it with the business before the budget is spent.
How is Datadog licensed for SLOs, incidents and on-call?
SLOs are built on the monitors and metrics you already send, so their cost follows the monitoring products underneath. Incident Management and On-Call are priced per seat per month, and Datadog lists its prices on its own pricing page. Interkey quotes the licences together with set-up and support in Saudi Arabia.
How long before SLOs and error budgets are useful to our team?
There is no fixed figure. It depends on how many services you start with, whether they are already instrumented, and how quickly owners agree targets. A first service with existing monitoring can have SLOs within weeks; a meaningful error budget needs at least one full window of data. Any duration we give is an estimate tied to that scope.
From the insights library
Continue in the glossary
More technology terms
Short, plain definitions of the terms buyers meet in monitoring, cloud and data projects.
Glossary termMTTR
How the time to recover from an incident is measured, and what shortens it.
SolutionDatadog Incident Management in Saudi Arabia
On-call, incident roles, postmortems, licences and support.
SolutionDatadog APM and distributed tracing
Following requests across services to find the slow or failing call.
Related pages
Next step
Set your first SLOs with us
Tell us which services matter most, how you monitor them today and how incidents are handled. We will suggest first SLIs and SLOs, and quote Datadog licences, set-up and technical support if Datadog 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