5 Critical Questions to Ask Your IT Provider Before Signing an SLA

An IT Service Level Agreement is a contract between you and your IT service provider that defines exactly what you are paying for — and what happens when it is not delivered. Done right, an SLA protects your business, holds your provider accountable, and gives your operations team a clear escalation path when things go wrong. Done poorly, an SLA is a document that looks comprehensive but contains enough vague language to make it functionally worthless when you need it most.

Most businesses sign IT SLAs without asking the questions that reveal whether the agreement will actually protect them. This guide covers the five most critical questions you must ask before signing any IT service agreement — whether you are procuring managed IT services, cloud infrastructure support, a helpdesk contract, or any other ongoing IT engagement.

Why Most IT SLAs Fail Businesses

Before diving into the questions, it helps to understand why IT SLAs so frequently fail to protect the businesses that sign them. The most common failure modes are vague definitions, hidden exclusions, and penalty structures that are too small to incentivise the provider to perform.

A provider might commit to “99.9% uptime” — which sounds excellent. But if their SLA defines “uptime” as server availability rather than application availability, your server can be running while your application is completely non-functional, and the provider is technically meeting their commitment. Similarly, “4-hour response time” means nothing if the SLA does not specify whether that is calendar hours or business hours, and whether response means acknowledgment of the ticket or actual work beginning.

Understanding these distinctions before signing is not paranoia — it is basic due diligence. The five questions below are the ones experienced IT managers, procurement teams, and legal advisors ask before committing to any managed IT services agreement.

Question 1: What Exactly Counts as Downtime — and How Is It Measured?

The word “downtime” appears in almost every IT SLA, but its definition varies dramatically between providers. Before signing, you need a precise answer to: what counts as a service being “down” for the purposes of this agreement?

The Uptime Calculation Problem

The standard uptime percentages — 99%, 99.9%, 99.99% — translate to very different amounts of acceptable downtime per year:

What to Ask

Push your provider to answer these specific questions about their uptime definition:

• Is uptime measured at the server level or the application level? A server that is running but serving errors is not providing uptime to your users.
• Does scheduled maintenance count against uptime? Providers often exclude planned maintenance windows from their availability calculation. If maintenance is every Sunday from midnight to 4AM, that is 208 hours per year — nearly 2.4% of annual hours — that may be excluded from their 99.9% commitment.
• How is downtime detected? If the provider only discovers outages when customers report them, their detection is slower and their calculation will always undercount actual downtime.
• What is the minimum duration before an outage counts? Some SLAs exclude incidents shorter than 5 or 10 minutes. Twelve 9-minute outages per month would be 108 minutes of real business impact that does not count against their SLA.

A provider that cannot answer these questions clearly is either unprepared or intentionally vague. Both are warning signs.

Question 2: What Are the Response and Resolution Time Commitments?

Response time and resolution time are two fundamentally different commitments — and confusing them is one of the most common mistakes businesses make when reviewing IT SLAs.

Response Time vs Resolution Time

Response time is how quickly the provider acknowledges your incident. An automated email from a ticketing system technically meets a “1-hour response time” commitment. It tells you nothing about when your problem will actually be fixed.

Resolution time is how quickly the provider resolves the incident and restores normal service. This is the number that actually matters for your business operations.

A well-structured IT SLA separates both commitments by incident severity:

What to Ask

• Does “response time” mean a human response or an automated acknowledgment? Require the SLA to specify “acknowledgment by a qualified engineer” not just ticket receipt.
• Are response and resolution times in calendar hours or business hours? For a P1 critical incident at 11PM on a Friday, “4-hour resolution in business hours” means your system could be down until Monday morning.
• Who classifies the priority level — you or the provider? If the provider classifies incidents, they have an incentive to classify P1s as P2s to give themselves more time. Negotiate mutual priority classification or clear, objective definitions.
• What constitutes “resolution”? Is it restoration of service, root cause identification, or permanent fix? Many providers consider a workaround or temporary fix as a resolution.

Question 3: What Are the Financial Penalties for SLA Breaches — and Are They Meaningful?

An SLA without meaningful financial consequences is a document of aspirations, not a contract of obligations. If the penalty for failing to meet a commitment is smaller than the cost of meeting it, a rational provider will simply pay the penalty and continue underperforming.

The Typical Penalty Structure Problem

The most common IT SLA penalty structure awards service credits — a discount on future invoices. A typical structure might offer a 10% service credit for each hour of downtime beyond the committed uptime target. On a £5,000/month contract, 10% is £500 — but if the downtime caused £50,000 in business losses, the credit is economically irrelevant to the provider.

More problematic: service credits are applied to future invoices, which means they only have value if you continue the relationship. If a provider’s chronic underperformance causes you to switch providers, you may lose all accumulated credits.

What to Ask

• What is the maximum total credit available per month? Many SLAs cap credits at 30% or 50% of the monthly fee regardless of how severe the breach was. A cap of 30% on a £5,000 contract means the worst-case penalty is £1,500 per month — often insufficient to cover the actual cost of significant downtime.
• Are penalties paid as cash or service credits? Cash payments are stronger than credits because they have value even if you terminate the contract.
• Is there a right to terminate for persistent SLA failure? The most powerful clause is a termination right: if the provider misses their SLA commitments for more than X times in any rolling 3-month period, you can exit the contract without penalty. This creates a structural incentive for compliance.
• Does the SLA address consequential losses? Most IT service contracts explicitly exclude liability for consequential losses — lost revenue, customer churn, reputational damage. Understand this limitation clearly before signing.

Question 4: What Is Excluded from the SLA?

What an SLA excludes is often more important than what it includes. Exclusions are the mechanisms providers use to limit their liability for real-world scenarios that are statistically likely to occur. Every IT SLA will have exclusions — the question is whether they are reasonable or whether they create gaps large enough to drive a truck through.

Common SLA Exclusions to Scrutinise

Force majeure — Providers universally exclude “acts of God” including floods, earthquakes, and power cuts. This is reasonable. What is not reasonable is a force majeure clause so broad it covers any “circumstances beyond the provider’s control” — language vague enough to include their own hardware failures, staffing shortages, or network issues.

Third-party dependencies — If your provider relies on AWS, Azure, a CDN, or a DNS provider, failures in those systems may be excluded from their SLA even if they cause your service to be unavailable. Ask whether the provider’s SLA covers end-to-end service availability or only the components they directly control.

Changes made by the customer — Most SLAs exclude issues caused by customer-initiated changes. This is reasonable in principle, but overly broad language can mean that any change you made in the preceding 30 days can be cited as a contributing factor to exclude a claim.

Security incidents — Some IT SLAs explicitly exclude downtime caused by cyberattacks, DDoS, or ransomware. If cybersecurity incidents are a material risk to your business (and they are to every business in 2026), verify whether the SLA covers incident response obligations, not just infrastructure availability.

Undocumented systems — If your environment includes systems or configurations that were not formally documented during onboarding, some providers will exclude incidents affecting those systems. Ensure a thorough environment documentation process is part of your onboarding.

What to Ask

• List every scenario where the provider will not be bound by the SLA. Get a complete list, not a summary.
• How does the provider handle issues caused by third-party components they manage? If they chose the third party, they should own the outcome.
• If we make a change that you advised against and it causes an incident, are you still obligated to respond within SLA? The response obligation should be separate from the liability question.

Question 5: How Is the SLA Measured, Reported, and Disputed?

An SLA is only as good as its measurement methodology. If the provider measures their own compliance against their own systems without external validation, you have no independent verification of whether commitments are being met. This is the governance question — and it is the one most commonly overlooked.

Measurement and Reporting

A transparent IT service provider will have:

• An external monitoring system — uptime and availability measured by a third-party tool (Pingdom, UptimeRobot, Datadog, or equivalent) whose data is accessible to the customer, not just internal monitoring that the provider controls
• A customer portal — real-time and historical performance data visible to you without requesting it
• Monthly SLA reports — delivered automatically, covering uptime achieved, incidents logged, response times met or missed, and credits earned if any
• Incident post-mortems — for P1 and P2 incidents, a written root cause analysis delivered within 5 business days explaining what happened, why, and what has been changed to prevent recurrence

The Dispute Process

When you believe an SLA has been breached and the provider disagrees, what happens? This needs to be in the contract. A fair dispute process:

• Defines who can raise a dispute and the time window for doing so (e.g., within 30 days of the relevant month’s SLA report)
• Requires the provider to respond in writing within a specified time
• Specifies an escalation path — account manager, then executive contact
• Identifies the evidence standard — what data sources are used to determine whether an SLA was breached
• Provides for a third-party mediator if internal escalation fails

What to Ask

• What monitoring tools are used, and do I have direct read access to the monitoring data? If the answer is “we send you a monthly report,” push for a customer portal with real-time access.
• How do I raise an SLA credit claim — and what is the process if you disagree with my claim? The answer reveals how adversarial the relationship will become when performance slips.
• How often is the SLA reviewed and updated? Your IT environment will change over time. The SLA should have an annual review process to ensure commitments remain relevant to your actual infrastructure.

Putting It Together: What a Strong IT SLA Looks Like

A strong IT SLA is concise, specific, and balanced. It does not need to be 40 pages long — in fact, longer SLAs are often more permissive for the provider, not more protective for the customer, because exclusions and qualifications accumulate. The strongest IT SLAs share these characteristics:

• Specific, objective definitions — downtime, incidents, priority levels, and response all defined without ambiguity
• Business-hours clarity — every time-based commitment specifies calendar hours, business hours, or 24/7
• Proportionate penalties — credits significant enough to create genuine financial incentive for compliance
• Termination for cause — a clear right to exit if performance persistently falls below commitments
• Third-party verification — monitoring data accessible to both parties
• Annual review — commitments that evolve with your infrastructure
• Narrow, defined exclusions — not blanket carve-outs for “circumstances beyond our control”

IT SLA Questions by Service Type

The five questions above apply universally, but their emphasis shifts depending on the type of IT service you are procuring:

Managed IT services / IT outsourcing: Focus heavily on Questions 1, 2, and 4. The breadth of services makes exclusion gaps particularly risky, and response time commitments need to cover the full scope of supported systems.

Cloud hosting / infrastructure: Questions 1 and 5 are paramount. Uptime definition and measurement methodology are the core commitments. Ensure third-party cloud components (CDN, DNS) are either covered or explicitly excluded with clear customer responsibility delineated.

IT helpdesk / user support: Question 2 dominates. Response and resolution times directly translate to user productivity. First-call resolution rates should be a defined metric, not just response times.

Cybersecurity services / SOC: Question 4 is critical. Understand precisely what incidents the SOC will and will not respond to, what escalation authority they have (can they isolate a server without your approval?), and what notification timelines apply.

Conclusion

The five questions in this guide will not make every IT SLA perfect — but they will reveal whether a provider has thought seriously about their obligations or is offering a template document designed to limit their liability. A provider that cannot answer these questions clearly, or that resists your attempts to get specific answers, is telling you something important about how they will behave when performance falls short.

The best IT service relationships are built on SLAs that both parties are genuinely comfortable with — where the provider believes the commitments are achievable and the customer believes the commitments protect their business. That alignment starts with asking the right questions before signing.