What is an SLA and why it matters for your IT support

Short answer: A Service Level Agreement (SLA) is the measurable promise an IT provider makes about how fast they will respond to your problems, how fast they will fix them, and what they guarantee about system uptime. A real SLA defines priority tiers, sets specific time commitments for each tier, and includes consequences when the commitments are missed. An IT support relationship with no SLA is not a service – it is a best-effort arrangement dressed up in a monthly invoice. This article walks through what SLAs actually contain, typical SMB-grade numbers, the difference between response and resolution time, how availability SLAs work, and the red flags that signal an SLA is hollow.

The short version, at a glance

Concept	What it means	Typical SMB range
Response time SLA	How long until a human responds to your ticket	15 min (critical) to 1 business day (low)
Resolution time SLA	How long until the issue is actually fixed	4 hours (critical) to 3 business days (normal)
Availability / uptime SLA	% of time a managed system stays up	99.9% is the standard SMB commitment
Priority tiers	How tickets are classified (P1-P4)	4 tiers is standard
Service credits	Compensation when SLA is missed	5-25% of monthly fee, per miss
SLA exclusions	What does not count against the SLA	Scheduled maintenance, force majeure, third-party outages

The rest of the article expands each row.

What an SLA actually is

A Service Level Agreement is a section of an IT support contract that translates vague promises (“responsive support,” “fast turnaround”) into numbers. The numbers are measurable, they are tracked, and they have consequences when the provider misses them.

Every real managed IT or MSP engagement has an SLA section in the contract. It is part of the eight sections every managed IT services agreement should contain. A “commitment to responsive service” without specific numbers is marketing copy, not an SLA.

SLAs matter because:

• They translate expectations into something you can audit. “Did the MSP respond within the SLA?” has a yes/no answer if the SLA is numerical. It has only opinions if the SLA is vague.
• They protect you when things go wrong. An SLA gives you recourse when the MSP underperforms – service credits, escalation rights, or in severe cases, termination rights.
• They force the MSP to build operational discipline. Providers who commit to a 15-minute response SLA on critical incidents need processes, tooling, and staffing that support it. Providers without SLAs can staff however they want.
• They make comparison shopping meaningful. Two MSPs quoting similar monthly fees can have wildly different SLAs. That delta is often the difference between real managed IT and break-fix support with a monthly fee attached.

Response time vs resolution time: the most important distinction

This is where weak SLAs hide their weakness. Many MSPs commit to response time but stay vague on resolution. A ticket can be “responded to” in 15 minutes and then sit unresolved for days. Response without resolution is not actually service.

Response time

Response time is the window from when you submit a ticket to when a human meaningfully responds. Auto-replies do not count. A templated “we received your ticket” does not count. Response time starts ticking when the ticket is submitted and stops when a real person engages with the issue.

Typical response time tiers:

Priority	Example scenario	Typical response SLA
P1 – Critical	Business-down, multiple users affected, active security incident	15-30 minutes
P2 – High	Single user blocked from all work, major function impaired	1-2 hours
P3 – Normal	Inconvenience, workaround exists, single user slowed down	4-8 business hours
P4 – Low	Request rather than a problem (install software, new account setup)	1-2 business days

These are commitments, not averages. An SLA is the provider saying “we will meet this time in X% of tickets” (typically 95% or higher). Missing an SLA once is normal. Missing it consistently is an operational failure.

Resolution time

Resolution time is the window from ticket submission to the issue being actually fixed. Not “we are working on it.” Not “we have identified the cause.” Fixed.

Resolution time is harder to commit to than response time because some issues have genuine external dependencies – a Microsoft outage, a hardware part on order, a third-party vendor that needs to make a change. Good MSPs commit to resolution targets anyway, with defined exceptions for external dependencies.

Typical resolution time tiers:

Priority	Typical resolution SLA
P1 – Critical	4-8 hours
P2 – High	1 business day
P3 – Normal	2-3 business days
P4 – Low	5 business days or scheduled

Why response-only SLAs are a warning sign

If an MSP commits only to response time, they are structurally incentivized to respond quickly and then stall. The ticket stays open, the SLA clock has already stopped, and there is no contractual pressure to actually close the loop. A good MSP runs on both response and resolution commitments because those are the two metrics that determine whether the service is real.

Priority tiers: how tickets get classified

The priority level of a ticket determines which SLA applies. This is where vague contracts create exploitable ambiguity.

What a good priority framework looks like

Clear, specific definitions per tier. Not “high priority means urgent.” Specific examples of what counts as P1 vs P2 vs P3 vs P4.

Example framework:

• P1 (Critical): Active ransomware, complete M365 outage, primary business application completely unavailable, security incident requiring containment, production server down.
• P2 (High): Single user cannot work (locked out, laptop dead, VPN not connecting with no workaround), major feature of a business app broken, email delivery delayed by more than 15 minutes, partial outage affecting multiple users.
• P3 (Normal): Single user experiencing friction (slow performance, intermittent issue, peripheral not working), software behaving unexpectedly, printing issues, request with workaround available.
• P4 (Low): New software install, new account provisioning, routine access change, documentation request, non-urgent question.

Red flag: MSP-controlled priority

Some contracts give the MSP sole discretion to assign priority. That lets them downgrade your “my entire team is blocked” ticket to P3 because their internal workload is heavy that day. Your SLA should include language that priority is assigned mutually, or that the client can escalate priority assignment if they disagree.

Red flag: “After hours” priority rules that do not match urgency

Some contracts define P1 as “business-hours-only” and everything after hours becomes P2 regardless of severity. A ransomware incident at 10pm on Saturday should be P1 no matter the clock. Make sure priority definitions are severity-based, not time-based.

Availability SLAs: the uptime commitment

For systems the MSP manages directly (firewalls, network equipment, cloud tenants they administer, sometimes hosted servers), availability SLAs commit to how often the system stays up.

The 9s table

Availability is usually expressed in “nines.” The more nines, the more uptime:

SLA	Downtime per month	Downtime per year
99% (two nines)	7 hours 18 minutes	3 days 15 hours
99.5% (two-and-a-half nines)	3 hours 39 minutes	1 day 19 hours
99.9% (three nines)	43 minutes	8 hours 45 minutes
99.95%	21 minutes	4 hours 22 minutes
99.99% (four nines)	4 minutes 19 seconds	52 minutes

99.9% is the standard SMB-grade commitment. Four nines is enterprise-grade and costs meaningfully more. Two nines is hobbyist-grade and should not be acceptable for anything business-critical.

What counts as “downtime”

The definition matters. A good availability SLA is specific:

• Complete outage of the covered system counts as downtime.
• Degraded performance that makes the system unusable typically counts as downtime, though less consistently.
• Individual user issues do not count as system downtime (those are ticket SLAs).
• Scheduled maintenance is usually excluded, but windows should be defined up front, not at the MSP’s discretion.

What “excluded” typically means

Availability SLAs almost always exclude:

• Scheduled maintenance windows (announced in advance)
• Third-party outages the MSP does not control (Microsoft, AWS, ISP)
• Force majeure events
• Issues caused by client-initiated changes

The exclusions should be specific. “Any downtime we decide is excluded” is not an exclusion list – it is the absence of a commitment.

Service credits: making the SLA have teeth

An SLA without consequences is a suggestion. Service credits are the most common way MSPs compensate clients when SLAs are missed.

How service credits work

Typical structure:

• Each missed SLA triggers a credit equal to X% of the monthly fee
• Multiple misses in the same month stack up to a cap (often 25% of monthly fee)
• Credits are applied to the following month’s invoice
• Chronic misses (3+ months in a row, or >3 misses in one month) trigger escalation rights or termination rights

Example service credit clause

“If MSP fails to meet the P1 Response SLA, client shall receive a credit of 5% of the monthly fee for each such failure, up to a maximum of 25% of monthly fee in any single month. If MSP fails to meet the P1 Response SLA in three consecutive months, client may terminate the agreement with 30 days notice and no early termination fee.”

That example has three elements that matter:

1. Specific credit amount per failure.
2. A cap on credits per month (protects the MSP from catastrophic exposure, which would make them unwilling to sign tight SLAs in the first place).
3. Escalation to termination rights after chronic failure. Service credits alone are not enough because a chronically failing MSP can simply absorb the credits as a cost of doing business. Termination rights force them to actually fix their service.

Red flag: SLAs with no credits

“We target 99.9% uptime” without any credit clause is not a commitment – it is an aspiration. A real SLA has teeth.

Red flag: Credits that cap too low to matter

If the maximum monthly credit is 2% of fee, even a complete service failure costs the MSP almost nothing. Meaningful caps are in the 20-25% range.

Availability measurement: what gets counted, when, and how

If an SLA commits to 99.9% uptime, how the MSP measures uptime matters enormously.

Measurement period

• Monthly is the most client-friendly. Each month is its own measurement, missed targets trigger credits that month.
• Quarterly averages out short outages but can hide week-long issues if the rest of the quarter is fine.
• Annual makes the SLA essentially meaningless for all but catastrophic failures.

Demand monthly measurement.

Measurement method

Good SLAs specify:

• How uptime is measured (monitoring tool, sampling frequency, what counts as “up”)
• Who measures it (MSP’s own tools are standard; third-party measurement is enterprise-grade)
• How it is reported (monthly report showing actual uptime vs SLA target)
• How disputes are resolved (what happens when the MSP claims the system was up and you experienced it as down)

Red flag: no reporting

If the MSP commits to an uptime SLA but never reports on actual uptime, you have no way to know whether they are meeting it. Insist on monthly SLA performance reporting as part of the contract.

Why no SLA is a red flag in any IT support relationship

Some IT providers – especially smaller shops, accidental-MSPs, or hybrid break-fix/managed operations – will resist formal SLAs. Common reasons given:

• “We have always been responsive, our clients love us.” Fine, then document it.
• “SLAs are too rigid, we prefer a flexible approach.” Flexibility for the provider equals exposure for the client.
• “Our business model does not work with formal SLAs.” Then their business model does not work for a client paying for managed IT.
• “We would never miss our targets, so credits are unnecessary.” Then agreeing to them costs them nothing.

A provider who will not commit to measurable service levels is telling you what their service is worth: as much as you are willing to tolerate without recourse. For a family friend fixing the computer in their spare time, informal is fine. For a business paying thousands of dollars a month for managed IT, informal is malpractice.

Evaluating an SLA: questions to ask before you sign

When reviewing an MSP’s proposed SLA, work through:

1. Are both response and resolution SLAs defined? Response-only is half the service.

2. Are priority definitions specific and mutually agreed? Vague definitions give the MSP discretion to downgrade your tickets.

3. What is the availability commitment for each managed system? Any system without an availability SLA is one the MSP does not actually promise to keep up.

4. What is the measurement period and method? Monthly is standard; anything longer is a red flag.

5. Are service credits substantial enough to motivate performance? 5% per miss with a 25% cap is typical; less than that is not meaningful pressure.

6. Is there a path from chronic SLA failure to termination? Credits alone are not enough for systematic underperformance. (If you are already at the point where chronic SLA failure is the trigger, the switching playbook covers what to audit before giving notice and how to run the transition.)

7. Does the MSP report on SLA performance transparently? If they cannot show you their own numbers, they are not tracking them.

8. Are after-hours SLAs defined, or does everything drop to P3 outside business hours? Security incidents do not respect business hours.

9. Does the SLA cover what you actually depend on? Helpdesk is the obvious one, but what about managed systems, backups, security monitoring?

10. What is excluded, and is the exclusions list reasonable? A huge list of exclusions can gut the SLA.

These questions overlap with the broader how to choose an MSP evaluation framework. The SLA conversation is where an evaluation turns from marketing to measurable.

How SLAs relate to the rest of the MSP relationship

SLAs do not exist in a vacuum. They interact with several other contract elements:

Pricing tier. Tighter SLAs cost more. A 1-hour response SLA on critical issues is a different product than a 4-hour SLA. This shows up in MSP pricing models – premium tiers include tighter SLAs, entry tiers loosen them.

Coverage hours. A “24/7 SLA” is very different from a “business hours SLA.” Some MSPs offer 24/7 response for critical only, and business hours for everything else. Know which hours your SLA applies in.

Exclusions and out-of-scope work. An SLA applies only to in-scope work. If your question is about a line-of-business app that is out of scope, the SLA does not apply. The boundary matters.

Security and incident response. During a security incident, standard SLAs may be replaced by an incident response runbook with its own timing commitments. For ransomware or active compromise, “respond within 15 minutes” is the floor, not the commitment.

Escalation paths. When the MSP misses an SLA, what happens next? Good contracts define an escalation path – named contacts, a documented escalation process, a mechanism for getting leadership attention on a chronic issue.

How SLAs evolve over time

MSP relationships are multi-year. SLAs should not be set once and forgotten.

At onboarding. The initial SLA reflects current best-guess expectations. Some of those guesses will be wrong. (See what to expect in the first 90 days of MSP onboarding for how SLAs actually get wired up during the onboarding project, including when proactive SLAs start counting.)

At quarterly business reviews. Look at actual SLA performance. If the MSP is consistently meeting or beating targets, you may want to tighten them (at a pricing conversation). If they are consistently missing, the question is why – understaffing, wrong tooling, scope creep, or an SLA that was unrealistic to begin with.

At renewal. Renegotiate SLAs that no longer match your operational reality. A business with tighter uptime expectations (you are growing, you are in a regulated industry, you are customer-facing) needs tighter SLAs than the one you signed when you were smaller.

When something changes. New line-of-business apps, new offices, new compliance obligations, new remote workforce – all change what the SLA needs to cover. Revisit the SLA whenever the business changes meaningfully.

How Sequentur thinks about SLAs

Sequentur is a security-first MSP / MSSP for small and mid-sized businesses across the 15-to-250-employee range, including both general SMBs and regulated industries like healthcare, legal, financial services, and defense contractors. Our standard managed engagement includes a documented SLA with four priority tiers, response and resolution commitments per tier, and service credits for misses. Our security tier adds tighter commitments on security-related incidents (critical alert investigation within 15 minutes, 24/7) because that is where the cost of a slow response is highest.

We share our SLA performance with clients in regular reporting. When we miss in a scenario where a credit is warranted, we issue it proactively rather than waiting for the client to ask – though whether a credit applies depends on the specific circumstances of the miss (severity, root cause, whether exclusions apply). When we see a pattern of misses, we bring it up at the next business review with a remediation plan rather than hoping nobody noticed.

If you want to see how our SLA compares to what you have been quoted by other providers, or you are trying to figure out whether the SLA in your current contract actually has teeth, schedule a call. We will walk through the specifics with you. If your current SLA is adequate and the provider is meeting it, we will tell you that – switching providers over paperwork is not worth it if the service itself is working.