MSP SLAs Demystified: How to Read Response and Resolution Times Before You Sign

When you’re choosing a managed service provider (MSP), the Service Level Agreement (SLA) is often the most important – and most confusing – part of the contract.

It’s full of terms like response time, resolution time, P1 incident, uptime guarantees, and business hours support. On paper it all looks impressive. But will it actually protect your business when something breaks?

This guide is written for non-technical owners and managers of small and mid-sized businesses. By the end, you’ll be able to:

• Understand the basic SLA terms (in plain English)
• Spot common loopholes and “gotchas”
• Know what’s a reasonable expectation for an SME
• Use a practical checklist to evaluate MSP SLAs before you sign

SLA Basics in Plain English

What is an SLA in the context of an MSP?

A Service Level Agreement (SLA) is the part of your MSP contract that spells out:

• What services you’re getting
• How quickly the MSP will respond when there’s a problem
• How quickly they aim to fix different types of issues
• When support is available (hours, days, holidays)
• What’s included – and what’s not

Think of it as the rules of the road for your relationship. It’s not a marketing brochure; it’s a commitment you can hold them to.

If something important goes wrong – your email stops working, your key application goes down – the SLA is what determines whether:

• You get help in 10 minutes,
• You get help tomorrow, or
• You’re told, “Sorry, that’s not covered.”

Key SLA Terms (Without the Jargon)

1. Response Time

Response time is how long it takes the MSP to acknowledge your issue after you log it (usually by phone, email, or portal).

Important:

• A response does not always mean “someone is actively fixing the problem.”
• It often just means, “We’ve received your ticket and assigned a priority.”

Example:
You email “[email protected]” at 3:00 pm because you can’t access your CRM system. The SLA says “1-hour response time.”

• At 3:45 pm you get an email: “We’ve received your ticket and are investigating.”
• That’s the MSP meeting their 1‑hour response time, even if no one has started troubleshooting yet.

When reading an SLA, always ask:

“Does ‘response’ mean acknowledgement only, or does it mean someone begins working on the issue?”

We’ll come back to how to clarify this in the checklist.

2. Resolution Time

Resolution time is how long it takes the MSP to actually fix the issue or provide a workable workaround.

• A fix means the root problem is resolved.
• A workaround might mean they temporarily move you to a backup system or show you an alternative way to do the same job.

Example:
Your internet connection goes down at 10:00 am on a Tuesday.
The SLA for this type of “critical” incident might say “4-hour resolution target.”

Possible outcomes:

• Best case: By 12:00 pm they’ve worked with your internet provider, your line is back up, and you’re fully operational.
• Workaround case: At 12:00 pm they set you up with a 4G backup connection. It’s not as fast, but your key staff can work again. Full fix may come later when the ISP resolves the underlying fault.

Note the word “target”. Some SLAs promise “resolution targets,” not guarantees. That matters a lot – we’ll explore why in the loopholes section.

3. Business Hours vs. 24/7 Support

MSP SLAs usually define when they will respond to you:

• Business-hours support
  Typical: Monday–Friday, something like 8:00 or 9:00 am to 5:00 or 6:00 pm, excluding public holidays.
• Extended-hours support
  Sometimes 7:00 am–7:00 pm, or includes Saturdays.
• 24/7 support
  The service desk is available around the clock, including nights, weekends, and holidays.

This makes a big difference to what you can expect:

Example:

• Your email goes down at 3:00 pm Tuesday.
  • With business-hours support, this is handled within the normal SLA.
• Your email goes down at 8:30 pm Saturday.
  • With business-hours-only support, your SLA “clock” may not start until 9:00 am Monday, unless you’ve paid for 24/7 coverage or an after-hours option.

Always check:

• What exactly are “standard hours”?
• Are there different response times for during-hours vs. after-hours?
• Are some issues only handled during business hours (e.g., “how‑to” questions, projects)?

4. Priority Levels (P1, P2, etc.)

Most MSPs categorize issues into priority levels to decide which ones get attention first and how fast.

Common labels:

• P1 / Critical / Severity 1 – Business-stopping
• P2 / Major / High – Big impact, but not total outage
• P3 / Minor / Medium – Limited impact, fewer users or non-core system
• P4 / Low / Service Request – Routine requests, small issues, “nice-to-have” items

Each priority level should have its own response and resolution targets.

Here’s how it might look in practice:

• P1 (Critical) – “Entire company can’t access email or core system; storefront POS is down; ransomware attack.”
  • Example target:
    • Response: within 15–30 minutes (during hours)
    • Resolution: within 4–8 hours (aim)
• P2 (Major) – “Department can’t use a key system; serious performance issue slowing business but not a full stop.”
  • Example target:
    • Response: within 1 hour
    • Resolution: within 8–16 business hours
• P3 (Minor) – “Single user can’t print; odd error in a non-critical tool; minor bug or annoyance.”
  • Example target:
    • Response: within 4 business hours
    • Resolution: within 2–3 business days
• P4 (Request / Low) – “New user setup; password reset (if not automated); software install; small change.”
  • Example target:
    • Response: within 1 business day
    • Resolution: within 3–5 business days (or scheduled)

The danger: different MSPs define these priorities differently, and sometimes they decide the priority, not you. The SLA should clearly define each level in business terms, not technical ones.

5. Uptime / Availability

Uptime (or availability) is usually expressed as a percentage, such as “99.5% uptime per month.”

It means: “We aim to keep this system running and accessible for X% of the time.”

For example, 99.5% uptime per month allows for about 3.6 hours of downtime in that month.

Important points:

• Uptime is often quoted for specific systems (e.g., a hosted server, cloud service, or internet connection), not your entire IT environment.
• Force majeure (things beyond their control, like major internet backbone failures or natural disasters) are usually excluded.
• Uptime guarantees may come from a third party (e.g., Microsoft 365, your cloud provider), not the MSP itself.

For many SMEs, the more relevant part of the SLA is how fast the MSP will react and help you recover when there is downtime, rather than the percentage itself.

Common Loopholes and “Gotchas” in MSP SLAs

Many SLAs look impressive until you read the fine print. Here are the most common traps.

1. Vague Wording: “Best Effort,” “Target,” “Aspirational”

Phrases that should raise a flag:

• “We will use best efforts to resolve issues promptly.”
• “Our target response time is 1 hour.”
• “We aim to maintain 99.9% uptime.”

These phrases are not firm commitments. They give the MSP flexibility and make it hard for you to push back if they’re consistently slow.

Better wording looks like:

• “We will respond within 1 business hour, 95% of the time, measured monthly.”
• “We guarantee 99.5% uptime, excluding scheduled maintenance and force majeure events.”

You don’t necessarily need a “perfect” guarantee (and extreme guarantees cost more), but you should know what’s firm and what’s just marketing language.

2. “Response” vs. “Actually Working on It”

As mentioned earlier, response often just means they’ve read your ticket.

Some MSPs meet their SLA by:

• Auto-replying (“We have received your request”)
• Manually marking the ticket as “in progress”
  …even if no one is actively diagnosing the issue yet.

To avoid this:

• Ask the MSP to distinguish “acknowledgement time” from “work start time”.

See if they’ll commit to something like:

“For P1 incidents, a qualified technician will begin active work within 30 minutes of acknowledgement.”

Even if they won’t put that exact phrase in, the conversation will show you how seriously they take critical issues.

3. Business Hours Limitations and Holidays

Common fine print:

• “All response and resolution times are measured during business hours only.”
• “Public holidays and weekends are excluded unless a separate 24/7 support contract is in place.”

What this can mean in practice:

Example:
Your warehouse operation runs Saturdays. At 8:00 am Saturday, the Wi‑Fi goes down. Your SLA says:

• Response time for P1: 1 hour (business hours)
• Business hours: Monday–Friday, 9:00 am–5:00 pm

Result:
The SLA clock doesn’t start until 9:00 am Monday. Their 1‑hour response promise is technically still honored if they reply by 10:00 am Monday – but your Saturday shift was effectively on its own.

If you operate outside standard hours (e.g., hospitality, healthcare, e-commerce, warehousing), you may need:

• Extended-hours coverage
• Or at least an agreed emergency process for off-hours critical issues

4. Remote-Only Support (and Extra Charges for Onsite)

Many MSPs lead with remote support, which is efficient and often effective. But some problems still require someone onsite.

Check for phrases like:

• “This SLA applies to remote support only.”
• “Onsite visits are billed separately at X per hour.”
• “Onsite response times are subject to engineer availability and travel time.”

Consider:

• If you have multiple locations, warehouses, or manufacturing sites, remote-only might not be sufficient.
• Ask what happens when hardware fails – do they come onsite, or are you on your own to handle the physical device?

5. Exclusions: “Not Covered” Items

Important exclusions might include:

• End-of-life equipment (old servers, PCs no longer supported by the manufacturer)
• User-owned devices (personal phones, home computers used for work)
• Third-party hosted apps (line-of-business software run by another vendor)
• Non-approved changes (if staff install non-standard software)
• Unsupported operating systems (e.g., old, unpatched versions of Windows)

This doesn’t mean the MSP won’t help with these items, but they may:

• Not commit to specific response/resolution times
• Charge extra or treat them as “best effort” only

You should be clear on:

• What’s fully covered by the SLA
• What is “best effort”
• What’s out-of-scope or billable

6. Dependency on Third-Party Vendors

Your MSP may manage services that depend on other companies, like:

• Internet service providers (ISP)
• Cloud platforms (Microsoft 365, Google Workspace, accounting SaaS)
• Telecom carriers (VoIP phones, SIP trunks)
• Specialist application vendors (industry-specific software)

The SLA might say:

• “Resolution times are subject to third-party vendor performance.”
• “We are not responsible for outages caused by third-party providers.”

What this means:

• The MSP may not be able to control how quickly those vendors fix issues.
• However, they can usually still commit to how quickly they will escalate, track, and communicate with you.

A good SLA will clarify:

• How quickly they log tickets with the third party
• How often they’ll update you
• What they can do if the vendor is slow (e.g., failover options, backups)

7. Force Majeure and “Things Beyond Our Control”

Most contracts include force majeure clauses covering:

• Natural disasters (floods, earthquakes, extreme storms)
• Major power grid failures
• Large-scale internet backbone outages
• War, terrorism, civil unrest, etc.

In these cases, SLAs are usually suspended – which is standard.

What you can still ask:

• “What is your disaster recovery plan?”
• “What resilience options can we put in place (backups, multiple internet links, cloud failover)?”

Even if they can’t guarantee normal SLAs during a disaster, they can help you prepare so downtime and data loss are minimized.

8. How Performance Is Measured (Averages That Hide Bad Days)

Many SLAs say targets must be met on average over a period (e.g., monthly or quarterly).

For example:

• “We will respond within 1 business hour for P1 incidents 95% of the time, measured monthly.”

This is more realistic for the MSP, but it can hide:

• Several very bad days (multiple 3–4 hour response delays)
• Poor handling of one particularly critical incident

Ask for:

• A monthly SLA report, showing:
  • Number of tickets by priority
  • Response times vs. targets
  • Resolution times vs. targets
• Clarification on whether there are any penalties or credits if they consistently miss their targets.

Note: For many SMEs, credits will be small, but consistent underperformance is still a red flag about service quality.

Realistic, Evidence-Based Targets for SMEs

No MSP can deliver instant, perfect support at rock-bottom prices. Your goal is to find a sensible balance between cost and responsiveness, based on how critical IT is to your business.

Below are typical ranges that many SMEs might negotiate. These are not hard rules but starting points.

A. Suggested Targets by Priority Level

Assume standard business-hours support (e.g., Mon–Fri, 8:30 am–5:30 pm).

P1 – Critical (Business-Stopping)

Examples:

• Entire office can’t access the internet
• Core business system down (e.g., POS, ERP, practice management system)
• Email down company-wide
• Security incident (e.g., suspected ransomware, major data breach)

Typical, reasonable targets:

• Response (acknowledgement):
  15–30 minutes during business hours
• Work start (if specified):
  Within 30–60 minutes of acknowledgement
• Resolution target:
  4–8 business hours for a workaround or significant progress

For 24/7 coverage, the same response times can be offered out of hours, but expect to pay more.

P2 – Major (High Impact, But Not Total Outage)

Examples:

• A department can’t use a key app, but rest of business is functioning
• Severe performance issue on core system (very slow, but usable)
• Intermittent but frequent disconnections

Typical, reasonable targets:

• Response:
  Within 1 business hour
• Resolution target:
  8–16 business hours (1–2 business days)

P3 – Minor (Medium Priority)

Examples:

• Single user can’t print
• Non-critical software issue
• Minor bug in an internal system that doesn’t block work

Typical, reasonable targets:

• Response:
  Within 4 business hours
• Resolution target:
  2–3 business days

P4 – Low / Service Requests

Examples:

• New user account setup
• New software installation
• Small configuration changes
• “How‑to” questions

Typical, reasonable targets:

• Response:
  Same business day or within 1 business day
• Resolution target:
  3–5 business days, or scheduled within an agreed time window

For some service requests (like major onboarding or moves), it’s more realistic to agree scheduled dates than strict hour-based SLAs.

B. Business Hours vs. 24/7: What’s Reasonable?

Standard Business-Hours Support

For many office-based SMEs (professional services, agencies, normal 9–5 operations), business-hours support is often sufficient if:

• You don’t run critical processes at night/weekends
• You can tolerate limited downtime outside business hours
• You have clear processes to handle issues until support opens

In this case, you might:

• Accept that an issue at 7:00 pm Friday may only be addressed Monday morning
• Focus instead on strong response and resolution during core hours

When 24/7 or Extended Hours Make Sense

Consider extended or 24/7 options if:

• You run retail, hospitality, logistics, healthcare, or similar with evenings/weekends
• You have staff working across time zones
• You rely on online sales or customer portals that generate revenue outside 9–5

Options include:

• Extended hours only (e.g., 7:00 am–10:00 pm, 6 days a week)
• 24/7 for critical issues only (P1 incidents)
• “On-call” arrangements, where after-hours calls go to a smaller on-duty team

Costs rise as you demand faster and broader coverage. Be suspicious of:

• Very low-cost MSPs promising instant, 24/7 support; usually, either:
  • It’s heavily limited in reality, or
  • The quality may not be as advertised.

C. Onsite vs. Remote Support Expectations

Remote support can often handle:

• Software issues
• Email problems
• Microsoft 365/Google Workspace issues
• Configuration and access problems
• User questions

Onsite support is usually needed for:

• Hardware failure (e.g., server, network switch, cabling)
• New office setups or major moves
• Certain Wi‑Fi and network troubleshooting
• Some complex printing or specialized equipment issues

Reasonable expectations:

• Most day-to-day issues handled remotely within the SLA.
• Onsite visits may have:
  • A longer response time (e.g., 4–8 business hours for critical onsite work)
  • Additional costs or different pricing (e.g., travel time, minimum callout fees)

If your operations are very location-dependent (warehouses, manufacturing), consider:

• Having spare equipment onsite (hot-standby devices)
• Asking about onsite response for P1 issues within the same day

D. Different SLA Expectations by Issue Type

Outages (Systems Down)

• Should be treated as P1 or P2 depending on scope
• Expect fast response and continuous effort until a workaround is in place

Degradation (Slow but Working)

• Usually P2 or P3
• Prioritized based on how much it affects productivity

How-To Questions and Training

• Typically P3 or P4
• May be handled best-effort or scheduled for specific times
• For many MSPs, embedding self-service resources and occasional training is more effective than strict SLAs

Practical Checklist: Questions, Red Flags, and Tracking

Use this checklist when evaluating MSP SLAs. You can literally print or copy it and take it into your meetings.

A. Key Questions to Ask About the SLA

1. Definitions and Scope

• “Can you walk me through how you define P1, P2, P3, and P4 issues, in business terms?”
• “What specific services and systems does this SLA cover? What is out of scope?”
• “Does this SLA include both remote and onsite support? If not, how is onsite handled?”

2. Response vs. Resolution

• “In your SLA, what does ‘response time’ actually mean? Is it just acknowledgement, or when someone starts working on the issue?”
• “Do you define a target resolution time for each priority? Are these guarantees or just goals?”

3. Hours of Coverage

• “What exactly are your standard business hours?”
• “How are issues outside those hours handled? Are there different SLAs for after-hours?”
• “We operate X hours – which of our business hours are covered by your SLA?”

4. Prioritization and Classification

• “Who decides the priority level of an issue – us, you, or both?”
• “Can you provide examples of real incidents and how you would classify them?”

5. Third-Party Dependencies

• “If an issue is with our internet provider or cloud software, what do you commit to? How quickly will you log and escalate tickets with them?”
• “Do you provide a single point of contact for such issues, or do we also have to call the vendor?”

6. Reporting and Accountability

• “Do you provide regular SLA performance reports (monthly or quarterly) with response and resolution metrics?”
• “What happens if you consistently miss your SLA targets? Are there service credits or improvement plans?”

7. Exclusions and Extra Charges

• “What kinds of things are excluded from the SLA? Old devices, personal phones, third-party software?”
• “Are there any services that are time-and-materials only or billed separately?”
• “How are major projects (e.g., migrations, new office setups) covered – separate SOWs or part of the SLA?”

8. Security and Emergencies

• “How do you handle security incidents? Are they automatically P1?”
• “Is there a different process or faster escalation for suspected breaches or ransomware?”

B. Red Flags to Watch For

Be cautious if you see:

1. Overly vague commitments

• Lots of “best effort,” “where possible,” and “aim to” language without clear numbers.

2. Unrealistic promises at low cost

• 5-minute response 24/7 for all issues, for a price that seems too good to be true.
• Unlimited onsite support included with no clear limits or conditions.

3. No clear priority definitions

• SLA mentions P1/P2/P3 but doesn’t explain what they actually mean in business terms.

4. No reporting

• MSP can’t or won’t provide monthly/quarterly SLA performance reports.
• Little transparency on ticket volumes, response times, or resolution times.

5. Hidden limits

• “Unlimited support” but with clauses that exclude many common issues.
• Very limited business hours (e.g., 9–4) for a business that clearly operates longer.

6. Dependency disclaimers with no proactive help

• “We’re not responsible for third-party outages” without any promise about escalation or communication.

C. Terms You Should Ask to Be Rewritten or Clarified

• Replace generic “best effort” phrases with concrete targets where it matters (especially P1/P2).
• Clarify “response” vs. “work start” for critical incidents.
• Define priority levels in language that reflects your business impact (e.g., “cannot take customer payments” instead of “server CPU over 90%”).
• Make sure business hours are clearly stated and match your operational needs.
• Ask to list exclusions explicitly in a schedule or appendix so there are no surprises.

D. Getting Commitments in Writing

Verbal assurances like “We always treat P1s urgently” won’t protect you when things go wrong. Ask that important points discussed in sales meetings are:

• Added to the SLA or contract as written clauses, or
• Summarized in a Statement of Work (SOW) that the contract references

Examples to get in writing:

• “P1 incidents: response within 30 minutes during business hours, 95% of the time, measured monthly.”
• “Monthly SLA performance report will be provided within 5 business days of month-end.”
• “We will begin work on P1 security incidents immediately upon acknowledgement during business hours.”

E. How to Track Whether the MSP Is Meeting the SLA

1. Request Regular Reports

• At least quarterly, ask for a report including:
  • Total tickets by priority
  • Average and percentile response times
  • Average and percentile resolution times
  • Any missed SLAs and reasons

2. Spot-Check Critical Incidents

• For big issues you remember (e.g., “email down in March”), compare your memory with the ticket history:
  • When did they acknowledge?
  • When did they start work?
  • When was it resolved?

3. Listen to Staff Feedback

• Periodically ask team members:
  • “When you log a ticket, how quickly do you hear back?”
  • “Are repeat issues being properly fixed or just patched?”
  • “Do you feel they take critical issues seriously?”

4. Annual SLA Review

• Once a year, sit down with the MSP to review:
  • SLA performance
  • Changes to your business operating hours, critical systems, or risk profile
  • Whether the existing SLA is still appropriate

Adjust the SLA as your business grows or changes. For example, if you launch an e-commerce channel that sells heavily on weekends, you may need to upgrade to extended or 24/7 coverage.

Conclusion: Use the SLA as a Business Tool, Not Just Legal Fine Print

An MSP SLA doesn’t need to be mysterious or deeply technical. It should:

• Reflect how your business actually operates
• Protect you when serious issues occur
• Set realistic expectations for both you and the MSP
• Provide a framework for ongoing improvement, not a one-time promise

By understanding:

• The difference between response and resolution
• How priority levels work and how they’re defined
• The impact of business hours, exclusions, and third-party dependencies
• What typical, reasonable timeframes look like for SMEs

…you can read an SLA with confidence and negotiate terms that match your needs and budget.

Use the checklist, ask direct questions, and insist on clear, written commitments. A good MSP will welcome these conversations – because a clear, well-understood SLA is in their interest as well as yours.