An SLA - service level agreement - is the part of a contract that puts numbers on a promise. Instead of a supplier vaguely agreeing to 'fix things quickly', an SLA says exactly how quickly, how often the service will be available, and what happens if they miss. For any UK business paying for IT support, broadband, hosting or cloud, the SLA is where the marketing stops and the actual commitment begins. It pays to read it.
What an SLA really is
Strip away the formality and an SLA is a measurable promise. It turns soft assurances into hard, checkable numbers - the things you can hold a supplier to when something goes wrong.
It sits inside a wider contract but does a specific job: defining the level of service you are buying, in terms both sides can measure. 'We'll sort it' is a sentiment. 'A priority-one fault will get a response within 30 minutes and a fix target of 4 hours' is a service level agreement.
The numbers that actually matter
Most of an SLA's value is in a handful of figures. Learn these and you can read almost any IT contract with a clear eye.
- •Uptime / availability: the percentage of time a service is up, often shown as 'nines' - 99.9% sounds tiny but allows nearly nine hours of downtime a year.
- •Response time: how fast the supplier acknowledges a problem (note: not how fast they fix it - an easy thing to confuse).
- •Resolution / fix time: the target for actually solving it, usually banded by how serious the fault is.
- •Priority levels: how issues are graded, from 'whole business down' to 'minor query', each with its own targets.
- •Service credits: the money back or compensation you receive if the supplier breaches the agreed levels.
Decoding "nines" of uptime
Uptime percentages are where buyers most often fool themselves. The gap between 99% and 99.9% looks trivial on paper and is enormous in practice, so it is worth translating the marketing into real hours.
99% availability permits around 3.65 days of downtime a year. 99.9% (three nines) allows about 8.8 hours. 99.99% (four nines) allows roughly 52 minutes. Each extra nine costs significantly more to deliver, so the question is never 'how many nines can I get' but 'how much downtime can my business actually tolerate' - and you should not pay for five nines to run a service that could happily survive an afternoon offline.
Response time versus resolution time
This single distinction catches out more buyers than any other, and unscrupulous suppliers know it. A fast response time is easy to promise and means very little on its own.
Response time is how quickly someone acknowledges your ticket. Resolution time is how quickly the problem is actually fixed. A supplier can boast a '15-minute response' and still leave you down for two days, because the response clock stops the moment they reply 'we're looking into it'. Always check both - and check whether the resolution figure is a firm commitment or merely a 'target' (a softer word that carries no penalty).
What a good IT support SLA contains
For day-to-day IT support specifically, a fair SLA spells out the things you will care about at 9am on a bad Monday. If they are vague or missing, ask before you sign.
Look for clearly defined priority levels with examples, separate response and fix targets for each, the support hours actually covered (and whether 24/7 costs extra), how to log an issue and what counts as a P1 emergency, plus what is excluded. The strongest agreements also state service credits, so a breach has real consequences rather than just an apology. This is the backbone of any credible managed IT service, and it sits alongside related promises in areas like incident response and managed detection and response, where speed of reaction is the whole point.
Questions to ask before you sign
An SLA is only as good as your willingness to test it before committing. A reputable supplier will welcome these questions; a cagey answer tells you plenty.
Ask: are these resolution figures commitments or 'targets'? What are the service credits if you miss? Are support hours business-only or round the clock? How are priorities decided - and who decides? And crucially, how is performance reported back to me, so I can actually see whether the SLA is being honoured? Strong SLAs matter most where downtime hurts most, which is why they go hand in hand with a solid backup strategy and a clear plan for backup and disaster recovery - the SLA covers the supplier's response, your backups cover everything else.