SLA — IT definition

A SLA (Service Level Agreement) is the measurable contractual commitment from a service provider — internal or external — on the quality of an IT service. It defines, in advance, acceptable parameters (availability, response time, RTO, incident resolution time), how they are measured, and the consequences of breach (penalties, credits, termination rights).

The SLA is the legal artifact that converts an intent ("we'll do our best") into an auditable obligation ("99.9 % monthly availability, measured by X, otherwise Y % credit"). With SaaS and cloud, the SLA has become the centerpiece of the customer-vendor relationship — and one of the most expensive blind spots when it isn't read carefully.

Common SLA indicators

• •Uptime: percentage of time the service is operational — often expressed in nines (99 %, 99.9 %, 99.99 %).
• •Response time: average or percentile latency (p95, p99).
• •Time to Respond: delay between report and first vendor response.
• •Time to Resolve / [MTTR](#): delay between report and full restoration.
• •[RPO](/en/glossary/rpo): maximum tolerated data loss on disaster.
• •[RTO](/en/glossary/rto): time to restore after disaster.
• •Incident severity: a P1-P4 grid with differentiated SLAs.

Understanding the nines

The advertised availability is often decisive — and misleading unless you convert it to actual yearly downtime:

• •99 %: 3 days 15 h of downtime per year.
• •99.5 %: 1 day 19 h per year.
• •99.9 %: ("three nines"): 8 h 45 min per year.
• •99.95 %: 4 h 22 min per year.
• •99.99 %: ("four nines"): 52 min per year.
• •99.999 %: ("five nines"): 5 min per year.

Moving from 99 % to 99.99 % typically multiplies cost by 100, not 10 — the trade-off has to reflect actual business value. An e-commerce site and a document management tool don't need the same target.

SLA, OLA, UC: the commitment chain

Three connected acronyms:

• •SLA (Service Level Agreement): contract vendor ↔ customer.
• •OLA (Operational Level Agreement): internal commitment between teams (the network team commits to the support team, for instance).
• •UC (Underpinning Contract): subcontracting contract with a third party, supporting the vendor SLA.

Golden rule: an external SLA can never be better than the worst OLA or UC underpinning it.

Reading a SaaS SLA carefully

Common traps in SaaS SLAs:

• •Scope: does availability cover the whole application or only the core service? Secondary modules are often excluded.
• •Exclusions: planned maintenance, force majeure, third-party incidents, DDoS — all common, sometimes extensive.
• •Calculation method: what window is availability measured over? Monthly? Yearly? Weighted by criticality?
• •Capped penalties: most SaaS SLAs cap credit at 10-25 % of the monthly fee — far below the actual cost of downtime.
• •Notification window: penalties only apply if you report the incident within a short window (often 30 days).

SLA vs SLO vs SLI: the SRE vocabulary

Site Reliability Engineering, popularized by Google, introduces three levels:

• •SLI (Service Level Indicator): the raw measurement (% successful requests over the last 5 minutes).
• •SLO (Service Level Objective): the internal target ("we aim for 99.95 % successful requests per month").
• •SLA: the contractual commitment, usually less ambitious than the SLO to keep a safety margin.

An SLO should always be tighter than the corresponding SLA to absorb the unexpected.

Why SLAs are a governance issue

For a CIO, SLA management is part of IT governance:

• •Align vendor SLAs with the SLAs you promise to internal business stakeholders.
• •Reflect actual application criticality in the SLAs — often unknown without an up-to-date application map.
• •Measure vendor performance in regular contractual review meetings.
• •Renegotiate SLAs at renewal based on actual usage and observed downtime cost.

Kabeen automatically ties business criticality, application dependencies, and contractual SLAs to give the CIO a steerable view of commitments.