Service level agreement (SLA)
Also known as: SLA, service level agreement, response time guarantee, service levels
A service level agreement (SLA) is a documented agreement between you and a service provider (like your MSP) defining what service to expect: response and resolution times, availability targets, scope of support, and responsibilities.
It sets clear, measurable expectations and provides accountability, so 'good service' isn't left to interpretation.
Service level agreement (SLA), explained at three levels
At home
An SLA works like a pizza place's promise to deliver within 30 minutes. It writes down what a service provider commits to, such as how fast someone answers when you report a problem, what hours they cover, and what they will fix. Because the promises are written and measurable, you can check afterward whether they were actually kept.
At work
A service level agreement is the part of a service contract that defines measurable service targets. For an IT provider, it usually covers response times by priority, support hours, availability targets, what is in and out of scope, and what each side is responsible for. Businesses care because it replaces 'good support' with numbers they can track and enforce.
At home
Most IT SLAs are built around a priority matrix. Each issue is ranked by impact and urgency: a server down for everyone might be Priority 1, with a response target of 15 minutes to an hour, while one person's printer question might be Priority 4, answered next business day. The clock usually starts when the ticket is logged and pauses outside covered hours, so those rules tell you what to expect at night or on weekends.
At work
An SLA separates several measures. Response time is how quickly a technician acknowledges the issue and starts work. Resolution time is how long until it is fixed, and is usually a target rather than a guarantee. Availability is uptime expressed as a percentage, where 99.9% still allows about 8.8 hours of downtime a year. The ticketing system timestamps each step, so monthly reports can show how often each target was met.
At home
The tricky part of an SLA is what counts. A provider can meet a one-hour response target with an automated email saying 'we got your ticket', so look at how 'response' is defined. Availability figures can also exclude planned maintenance windows. Remedies are often service credits, a small discount on next month's bill, not real compensation. While SLAs look like legal protection, in my opinion their real value is the monthly report that shows whether service is slipping.
At work
Mature SLAs sit within an IT service management framework such as ITIL, which separates the customer-facing SLA from internal operational level agreements and from underpinning contracts with third parties like an internet provider. Targets should map to business impact, with critical systems given tighter tiers. Watch for exclusions, clock-stopping rules and caps on credits. A quarterly service review comparing SLA data with ticket trends turns the agreement into a governance tool rather than a forgotten contract clause.
Real-world examples
At home
Thomas's previous IT help was hit-or-miss on response times with no accountability. His new MSP's SLA guarantees a response within an hour for critical issues and defines exactly what's covered, so he knows what to expect and can hold them to it.
At work
Nadia's firm negotiated an SLA specifying one-hour response for critical outages, next-business-day for minor issues, defined coverage hours, and monthly performance reporting. When response times slipped one month, the SLA gave her a concrete basis to raise it, and the MSP corrected course.
Common confusions
- An SLA guarantees my problem will be fixed within a set time — SLAs usually guarantee response time (how fast they start), not resolution time, because complex issues vary. Look at response commitments and prioritization rather than expecting a fixed fix-time for everything.
- An SLA is just fine print that doesn't matter — The SLA defines exactly what service you're entitled to and provides accountability. Understanding it prevents mismatched expectations and gives you a basis to address poor service.
- All the responsibilities in an SLA are the provider's — SLAs typically define client responsibilities too (like providing access or approving changes). Meeting your side of the agreement is part of getting the service you expect.
For analysts
Read the SLA before signing, focusing on response times by priority, coverage hours, what's in and out of scope, and your own responsibilities. It converts 'good support' into measurable commitments, and gives you an objective basis to hold your provider accountable.
History & origin
SLAs originated in telecommunications and IT outsourcing as a way to formalize service expectations and hold providers accountable with measurable targets. As managed services grew, SLAs became standard in MSP contracts, defining response times, priorities, and coverage. They evolved to balance clear commitments with practical realities, giving both provider and client a shared, objective definition of acceptable service.