A service level agreement defines what your IT provider commits to, in measurable terms, and what happens if they fail to deliver it. Almost every managed IT contract contains one. Far fewer contain one that means anything.
The difference lies in four places: how severity is defined, whether the commitment is to respond or to resolve, what is excluded, and whether missing the target has any consequence at all.
Severity definitions come first
Everything else in an SLA depends on how incidents are classified, because the classification determines which target applies. A well-drafted agreement defines severity by business impact rather than technical symptom.
A typical structure:
- Critical — the business cannot operate. Server down, site-wide outage, ransomware, no email for anyone.
- High — a department or critical function is blocked. One team cannot access their application; a shared resource is unavailable.
- Medium — an individual is blocked but has a workaround, or a non-critical system is degraded.
- Low — requests rather than faults. New user setup, software installation, questions.
The detail to check: who assigns severity? If the provider classifies unilaterally, they control which target applies to every ticket. The better arrangement lets you flag severity on submission, with a defined process for disagreement.
Response is not resolution
This is the most consequential misreading in the whole document.
Response time is how long until someone acknowledges the ticket and begins work. Resolution time is how long until the problem is fixed. Nearly all SLAs commit to the first, and very few commit to the second.
That is defensible — a provider cannot guarantee how long an unknown fault will take, and a hardware failure requiring a replacement part is outside their control. But you should know which you are being promised, because "one hour response" and "one hour to working again" are wildly different things, and proposals rarely make the distinction prominent.
The useful middle ground some providers offer is a commitment to continuous effort on critical incidents — work continues without interruption until service is restored, rather than a fixed resolution deadline. That is meaningful and achievable.
The clause that gives an SLA teeth
Ask what happens when a target is missed. If the answer is nothing, the SLA is a statement of intent.
Common remedies:
- Service credits — a percentage of the monthly fee refunded per breach. Usually modest, but they create a real internal incentive at the provider.
- Escalation rights — a defined path to a named senior contact once a threshold is crossed.
- Termination rights — repeated breaches within a period constitute material breach, allowing exit without penalty. This is the most valuable of the three.
That third one is worth pushing for specifically. Service credits are small; the right to leave a provider who consistently underdelivers is not.
Exclusions and measurement windows
Two mechanisms quietly narrow most SLAs.
Exclusions typically remove third-party failures, force majeure, scheduled maintenance, issues caused by client changes, and anything outside the contracted scope. Most are reasonable. The one to examine is third-party failure — if your internet carrier is down, that is genuinely not your provider's fault, but you still want a commitment that they will manage the vendor and keep you informed.
Measurement windows matter more than people expect. An SLA measured only during business hours means a Friday evening critical incident may formally begin its clock on Monday morning. If you need genuine out-of-hours coverage, confirm the clock runs then too.
Uptime percentages, in context
Some agreements include an uptime commitment. It is worth converting the percentage into time, because the figures are less impressive than they sound:
- 99% — about 7 hours 12 minutes of downtime per month
- 99.5% — about 3 hours 36 minutes per month
- 99.9% — about 43 minutes per month
- 99.99% — about 4 minutes per month
Also establish what the percentage applies to. Uptime on infrastructure the provider controls is a real commitment. Uptime on a third-party cloud service they merely resell is not theirs to promise.
Reporting
An SLA without reporting cannot be enforced, because you have no independent view of performance. The agreement should commit to regular reporting covering ticket volume, response times against target, breaches, and recurring issues.
Ask to see a sample report before signing. Ask specifically whether it shows breaches — some reporting is constructed to demonstrate compliance rather than to reveal performance, and the difference is visible immediately in the format.