MSP SLAs Explained: Response Time, Resolution Time and 24/7 Support
When an MSP promises a "15-minute response time," what are you actually getting? An automated email, or an engineer working on your problem? This guide breaks down what MSP SLAs really mean — and the questions you should be asking before you sign.
In brief: Most MSP "response time" guarantees only cover acknowledgement — not when an engineer starts working. A strong SLA should separately define acknowledgement time, engineer engagement time, restoration time and resolution time. It should also clarify whether "24/7 support" means automated monitoring, staffed engineers, or a manned NOC.
The Four Stages of Issue Handling
When you report a problem to your MSP, the resolution process has four distinct stages. Understanding these stages is critical because many SLAs only make guarantees about the first one.
Stage 1: Acknowledgement
Automated or manual confirmation that the issue has been received and logged into the ticketing system.
This is what most MSPs mean when they say "response time." An auto-generated email saying "Your ticket #4821 has been created" counts as acknowledgement. It tells you nothing about when a human will look at the problem.
Stage 2: Engineer Engagement
A qualified engineer begins actively working on the issue — not just triaging it, but diagnosing and troubleshooting.
This is the stage most businesses actually care about. The gap between acknowledgement and engineer engagement can be minutes or hours, depending on staffing and workload. Ask your MSP: "How long after acknowledgement does an engineer start working?"
Stage 3: Restoration
Service is restored to a functional state, even if a temporary workaround is in place rather than a permanent fix.
For critical outages, restoration is the most important milestone. Your email server is back up, your staff can log in again, your phones are working — even if the underlying cause hasn't been fully resolved yet.
Stage 4: Resolution
The root cause is identified and permanently fixed. The workaround (if any) is replaced with a lasting solution.
Resolution may come days or weeks after restoration. A good SLA will track both restoration time and resolution time separately, because they serve different purposes.
⚠️ Why this matters
Many MSPs guarantee "response time" which only covers Stage 1 — acknowledgement. A "15-minute response time" may mean you get an automated ticket confirmation in 15 minutes, while the actual engineer engagement doesn't happen for hours. When comparing MSPs, always ask: "Does your response time SLA cover acknowledgement, or does it guarantee when an engineer will start working on the issue?"
Monitoring vs Staffed Support — What Does "24/7" Actually Mean?
"24/7 support" is one of the most common claims in MSP marketing — but it means very different things depending on the provider. Here are the three models you'll encounter.
24/7 Monitoring
Automated alerting software watches your systems around the clock. If a server goes offline at 3am, the software detects it and may create a ticket or send a notification.
Who responds: No one — at least not immediately. A human reviews the alert when they come on shift, or if the alert triggers an on-call escalation.
Ask this: "If your monitoring detects a critical alert at 2am, what happens next? Does a human see it in real time?"
24/7 Staffed Support
A live engineer (or team) is available to take calls and respond to issues outside business hours — including weekends and public holidays.
Who responds: A real person answers the phone or responds to tickets. They may be an in-house engineer or an outsourced after-hours service.
Ask this: "If I call at 2am on a Saturday with a critical issue, who answers the phone and what's their technical capability?"
24/7 NOC (Network Operations Centre)
A manned operations centre with engineers actively watching dashboards, responding to alerts, and remediating issues in real time.
Who responds: On-shift engineers who are already at their workstations — no one needs to be woken up or paged.
Ask this: "Is your NOC staffed in-house, outsourced, or a hybrid? Where is it located?"
💡 The key question to ask any MSP
"If I call at 2am on a Saturday with a critical issue — such as a complete email outage or a ransomware attack — who answers the phone, what is their technical capability, and within what timeframe will an engineer begin actively working on the problem?"
The answer will tell you whether you're getting genuine around-the-clock staffed support or automated monitoring with best-effort escalation.
Essential SLA Components
Response Time Guarantees
Defined timeframes for each stage of issue handling, broken down by priority level. A good SLA will specify acknowledgement time and engineer engagement time separately.
What to Look For:
- Separate commitments for acknowledgement and engineer engagement
- Clear priority definitions (what qualifies as critical vs. high vs. low)
- Timeframes appropriate to your business — a medical practice needs faster response than a creative agency
- Different commitments for business hours vs. after hours
Red Flags:
- "Response time" defined only as acknowledgement, with no commitment on when work begins
- Same response time for all priority levels
- No definition of what constitutes each priority level
Restoration and Resolution Objectives
Target timeframes for getting you back to a working state (restoration) and for permanently fixing the underlying cause (resolution). These should be tracked separately.
What to Look For:
- Separate restoration and resolution targets
- Realistic timeframes that account for issue complexity
- Escalation procedures when targets are at risk of being breached
- Clear distinction between a workaround and a permanent fix
Red Flags:
- Only resolution time is mentioned, with no restoration commitment
- Unrealistically fast resolution promises (e.g., all critical issues resolved in under 1 hour)
- No escalation process when issues approach SLA breach
Availability Guarantees
Uptime commitments for systems and services your MSP manages. These should specify how uptime is measured and what counts as an exclusion.
What to Look For:
- Specific uptime percentages with clear measurement methodology
- Defined maintenance windows excluded from uptime calculations
- Different tiers for different services (network vs. email vs. line-of-business apps)
- Uptime measured from your perspective, not just at the data centre
Red Flags:
- Uptime commitments with no explanation of how they're measured
- Broad exclusions that could be used to dismiss genuine outages
- 100% uptime guarantees — these are unrealistic and suggest the provider hasn't thought it through
Performance Metrics and Reporting
Measurable standards for how your systems should perform, and how performance is tracked and reported to you.
What to Look For:
- Regular SLA performance reports (monthly at minimum)
- Access to a portal or dashboard showing ticket status and history
- Baseline measurements established at onboarding
- Trend analysis showing improvement or degradation over time
Red Flags:
- No reporting unless you request it
- The MSP self-reports with no independent verification
- Vague descriptions like "fast" or "optimised" with no measurable targets
What We Recommend Looking For
Note: These are editorial recommendations based on our review of Australian MSP contracts. They are not universal standards. Your requirements may differ based on business criticality, industry regulations, and the size of your IT environment.
Acknowledgement Time
For critical issues, acknowledgement should be near-instant if the MSP uses automated ticketing. For all other priorities, within 30 minutes during business hours is reasonable.
Engineer Engagement
For critical outages, a qualified engineer should begin working within an hour. For lower priorities, same-day or next-business-day engagement may be appropriate.
Restoration Time (Critical)
For outages affecting core business operations, aim for restoration within 4 hours — even if via a workaround. Complex infrastructure issues may take longer; the SLA should define escalation if this target is at risk.
Service Credits
Credits should be applied automatically when SLA targets are missed — not only when you complain. Look for credits that scale with the severity and duration of the breach.
Critical SLA Terms to Understand
Service Credits
Financial compensation provided when the MSP fails to meet SLA targets — typically a discount on the next month's invoice.
Why it matters: Without financial consequences, an SLA is just a statement of intent. Service credits give the MSP a tangible incentive to meet commitments.
What to Look For:
- Automatic credit calculation — you shouldn't have to chase the MSP to claim credits
- Credits proportional to the severity and duration of the breach
- Clear qualification criteria so there's no argument about whether a breach occurred
- A defined maximum credit cap per billing period
Exclusions and Limitations
Circumstances where SLA guarantees don't apply — for example, if your own staff caused the outage, or during a declared natural disaster.
Why it matters: Some exclusions are reasonable. Too many exclusions gut the SLA's value. You want a short, specific list — not a catch-all.
What to Look For:
- A short list of genuine exclusions (force majeure, client-caused issues, pre-approved maintenance)
- No blanket exclusion for third-party service outages — your MSP chose those vendors
- Maintenance windows scheduled at agreed times, not whenever the MSP decides
- Exclusions that are clearly defined, not open to interpretation
Escalation Procedures
The process for getting more senior staff or management involved when an issue isn't being resolved within SLA timeframes.
Why it matters: Escalation is your safety net. If the first engineer can't solve the problem, you need to know who gets involved next and when.
What to Look For:
- Automatic escalation triggers tied to SLA timeframes
- Named escalation contacts — not just "management"
- Customer notification at each escalation stage
- A clear path from engineer to team lead to account manager to senior leadership
Reporting and Monitoring
How the MSP measures SLA performance and communicates it to you — including the tools, frequency, and level of detail.
Why it matters: If performance isn't measured and reported, you have no way to know whether the MSP is meeting its commitments.
What to Look For:
- Monthly SLA performance reports sent proactively
- A client portal showing real-time ticket status
- Historical data you can review during contract renewals
- Willingness to discuss and explain any breaches
SLA Red Flags to Avoid
⚠️ Vague or Ambiguous Language
Example: "Best effort" response times, "reasonable" timeframes, or "as soon as practicable" without specific definitions
Impact: Allows the MSP to argue that any response was compliant. If it's not measurable, it's not enforceable.
⚠️ Excessive Exclusions
Example: Long lists of circumstances where SLAs don't apply — especially blanket clauses like "any issue involving third-party services"
Impact: Reduces the SLA to a best-case-only promise. Since most modern IT stacks involve third-party services, this could exclude the majority of real outages.
⚠️ No Financial Penalties
Example: SLAs with targets but no service credits, refunds, or termination rights for repeated breaches
Impact: Without consequences, the SLA is a marketing document. There's no incentive for the MSP to invest in meeting the commitments.
⚠️ Unrealistic Promises
Example: 100% uptime guarantees, instant response times, or promises to resolve any issue within 1 hour
Impact: No provider can deliver 100% uptime. Unrealistic promises suggest either inexperience or a willingness to promise anything to close the sale.
⚠️ No Measurement Methodology
Example: SLAs that define uptime targets but don't explain how uptime is measured, or what tools are used to track it
Impact: Creates disputes over whether targets were actually met. Both parties need to agree on how performance is measured before signing.
⚠️ "Response Time" Without Clarification
Example: "15-minute response time" with no explanation of whether this means acknowledgement, triage, or engineer engagement
Impact: You think you're getting an engineer working on your problem in 15 minutes. You're actually getting an automated email in 15 minutes.
SLA Negotiation Strategy
Before Signing
- Collect two or three SLAs from competing MSPs and compare terms side by side
- Request references from clients in your industry or of a similar size
- Ask the MSP to explain every defined term — if they can't, that's a concern
- Map SLA commitments to your own business requirements (e.g., if you trade online, what's the cost per hour of downtime?)
- Review penalty and credit structures — are they meaningful enough to create accountability?
Contract Terms
- Negotiate service credits that reflect the actual business impact, not just a token gesture
- Push back on broad exclusion clauses — request specific, enumerated exceptions
- Include a clause for regular SLA review (e.g., every 6 or 12 months)
- Define clear termination rights if SLA breaches are repeated
- Specify what happens to your data if the contract ends — formats, timeframes, costs
Ongoing Management
- Track SLA performance yourself — don't rely solely on the MSP's reporting
- Document every incident, including timestamps and communication
- Hold regular service review meetings (at least quarterly)
- Raise SLA concerns formally in writing, not just verbally
- Use SLA performance data as leverage during contract renewal negotiations
Need Help Evaluating an MSP SLA?
Understanding SLA terms is the first step. If you're comparing MSP proposals or reviewing a contract renewal, we can help you identify gaps and ask the right questions.
Frequently Asked Questions About MSP SLAs
What's the difference between response time and resolution time in an MSP SLA?
Response time typically refers to how quickly the MSP acknowledges your issue — often with an automated ticket confirmation. Resolution time is how long it takes to permanently fix the underlying problem. In between, there are two other important stages: engineer engagement (when a qualified person starts working on it) and restoration (when service is back to a functional state, even if a workaround is in place). A strong SLA will define separate commitments for each stage.
What does "24/7 support" actually mean from an MSP?
It depends on the provider. "24/7 monitoring" often means automated alerting software with no human watching in real time. "24/7 staffed support" means a live engineer can answer calls and respond outside business hours. "24/7 NOC" means a manned network operations centre with engineers on shift. Ask specifically: if you call at 2am on a Saturday with a critical issue, who answers and within what timeframe?
How do MSP service credits work?
Service credits are financial compensation — usually a discount on your next invoice — when the MSP fails to meet SLA targets. The credit amount typically scales with the severity and duration of the breach. Look for SLAs where credits are calculated and applied automatically, with clear criteria for what qualifies as a breach. Be wary of SLAs with no financial penalties at all.
What should I ask an MSP about their SLA before signing?
Key questions include: Does your response time commitment cover acknowledgement only, or engineer engagement? What are your restoration targets for critical outages? Is your after-hours support staffed by live engineers or handled by automated monitoring with on-call escalation? How do you measure uptime and how is it reported? What service credits apply if you miss your targets? Can you provide SLA performance data from existing clients?
Can I negotiate MSP SLA terms?
Yes. Most MSP SLA terms are negotiable, especially for contracts above a minimum spend. Focus on the areas that matter most to your business: response and restoration times for critical issues, meaningful service credits, limited exclusions, regular performance reviews, and clear termination rights if SLA breaches are repeated. Comparing SLAs from multiple providers gives you leverage in negotiations.