Core IT & Managed Services
SLA Tiers Explained: Response Time vs. Resolution Time
“4-hour SLA” means almost nothing on its own. The two numbers that matter — response and resolution — measure completely different things.
In this article
01
Response time vs. resolution time
Response is an acknowledgement clock; resolution is a fix clock. They need separate targets.
02
Why severity tiers exist
A P1 outage and a P4 cosmetic bug shouldn’t share the same clock — tiering keeps commitments realistic.
03
Reading an SLA before you sign
The fine print on business hours, exclusions and escalation triggers matters more than the headline number.
Response time vs. resolution time
Response time is how long it takes for a human to acknowledge your ticket — not fix it, just confirm it’s been seen and triaged. Resolution time is how long it takes to actually close the issue. A provider can hit a 15-minute response SLA and still take six hours to resolve a complex outage, and both numbers can be entirely compliant with the contract. If your SLA document only states one number, ask which one it is before you assume coverage you don’t have.
Why severity tiers exist
A production outage affecting every user and a single employee’s printer driver issue shouldn’t be held to the same clock. That’s why mature SLAs define severity tiers — typically P1 (critical, business-stopping), P2 (major, degraded but working), P3 (minor, workaround available), and P4 (cosmetic or low-impact) — each with its own response and resolution targets. A reasonable baseline looks like: P1 response within 15–30 minutes, resolution target within 4 hours; P2 response within 1 hour, resolution within 8 business hours; P3/P4 handled within the next business day or two.
Reading an SLA before you sign
The headline number on a sales deck is rarely the whole story. Before signing, check: is the clock measured in business hours or calendar hours? What counts as a valid escalation trigger if the target is missed? Are there exclusions for third-party outages, planned maintenance, or client-caused issues? And critically — what happens when the SLA is breached? A credit against the invoice is common, but it rarely compensates for the actual business impact of a missed P1 resolution.
The practical check: ask your provider for their SLA attainment rate over the last two quarters, by tier, not just the target. A target with no track record behind it is a promise, not a commitment.
Making the SLA operational, not just contractual
An SLA only works if it’s tied to a real escalation path and measured monthly. Ask for a monthly SLA performance report broken down by severity tier, and agree in advance on what triggers escalation to a named contact when a ticket is at risk of breaching. Without that reporting cadence, an SLA is a clause in a contract nobody checks until something goes wrong.
Frequently asked questions
What's a reasonable SLA for a critical (P1) incident?
A common baseline is 15–30 minute response and a 4-hour resolution target for P1 incidents, though the right number depends on your environment’s complexity and whether coverage is 24/7 or business-hours only. The target should be realistic enough that the provider can consistently hit it — an aggressive SLA on paper that’s never met is worse than a modest one that always is.
Does a missed SLA mean we get our money back?
Usually it means a service credit against a future invoice, defined in the contract — not a refund, and rarely full compensation for business impact. Review the remedy clause carefully; it tells you how seriously the SLA is actually enforced.
Can SLA targets differ by system, not just by severity?
Yes, and they often should. A customer-facing production system and an internal reporting tool shouldn’t necessarily share the same resolution target even at the same severity — many contracts tier by both severity and system criticality.