Every managed services proposal contains a table of promises. One hour response. 99.9% uptime. Priority support. The table looks reassuring, which is the point. It is also the part most business owners skim, because it reads like it was written by a lawyer arguing with an engineer. It sort of was.
A service level agreement, or SLA, is the section of a contract that defines what performance you are actually owed and what happens when you do not get it. Read properly, it is one of the most useful documents in the relationship. Read carelessly, it lets a provider look fast on paper while your server sits dead until Monday. Here is how to read one, in plain English, without needing to know what any of the acronyms stand for.
Response Time Is Not Resolution Time
This is the single most common misunderstanding, and it is worth being blunt about it. Response time is how long until somebody acknowledges your problem. Resolution time is how long until the problem is actually fixed. As UptimeRobot’s SLA guide puts it, response time is the duration between when a customer reports an issue and when the provider acknowledges it, while resolution time spans from the report to complete resolution.
A one hour response guarantee means you get a human within an hour. It says nothing about when you get your email back. Most providers, including us, are careful not to guarantee resolution times, and there is an honest reason for that: some fixes depend on a hardware vendor, a software company, or an internet carrier that we do not control. Promising a fix time we cannot control would be a promise we could not keep.
What you should expect instead is a commitment to communication. Ask whether the agreement includes update intervals: will someone tell you where things stand every hour, every two hours, or only when they feel like it? A provider who will commit to regular updates during an outage is telling you something real about how they operate.
Business Hours, Severity Levels, and When the Clock Runs
The clock in an SLA does not always run. Three definitions decide when it does.
- Business hours. Find the exact definition and the time zone. Eight to five Central, Monday through Friday, excluding published holidays is a normal answer. What matters is what happens at 5:01 p.m. A ticket submitted then may not start its clock until 8 a.m. the next business day, which turns a stated four hour response into fifteen real hours.
- After hours coverage. Ask whether it exists, what it costs, and how you reach it. An emergency line that rolls to voicemail is not coverage. Also ask who answers: a technician who knows your environment, or an answering service that takes a message.
- Severity levels. Most agreements sort tickets into three or four tiers. Severity one usually means the business is stopped: the server is down, nobody has email, the internet is out. Severity two means one department or a critical function is impaired. Severity three is a single user with a broken printer. Severity four is a request rather than a problem.
- Who assigns the severity. This is the question almost nobody asks and it decides everything. If the provider classifies tickets unilaterally, every promise above becomes flexible. Look for language that lets you declare severity one, with a reasonable check on abuse.
What an Uptime Percentage Means in Actual Minutes
Uptime percentages sound impressive until you convert them into time, which is the only form that matters when your team is standing around. UptimeRobot’s guide lays out the standard math: 99% uptime allows roughly 7.2 hours of downtime per month, 99.9% allows roughly 43.8 minutes per month, and 99.99% allows roughly 4.38 minutes per month. Over a year, 99.9% works out to about 8.77 hours.
That last number is worth sitting with. The 99.9% figure that vendors print on marketing pages is a full business day of outage per year, and it is completely within the promise. Your cloud providers make the same commitment. Google’s published Google Workspace service level agreement, for example, commits to a Monthly Uptime Percentage of at least 99.9% in any calendar month, and defines Downtime as a period during which the user web interface has more than a five percent user error rate. Note the definition. Slow is not down. Broken for a few people is not down.
This is where Harrison’s line earns its keep: the cloud is just someone else’s computer, and someone else’s computer has maintenance windows too. We wrote more about planning for that in our post on what a cloud outage means for your business.
The Exclusions Do the Real Work
Every SLA has a section listing what does not count. It is usually short, boring, and the most consequential paragraph in the document. UptimeRobot’s guide names the usual suspects: planned maintenance, partial outages affecting only some users, third party failures, and force majeure events. Google’s Workspace SLA similarly excludes issues resulting from factors outside its reasonable control, customer equipment, and third party equipment.
None of that is unreasonable. Read it anyway, and ask two questions. First, how much notice do you get before planned maintenance, and can you object to a window that lands during your busiest hours? Second, if a third party outage is excluded, who coordinates the fix? Your provider should still own the vendor call even if the clock is paused.
Then look at the remedy. Most agreements pay out in service credits rather than money. Google’s Workspace SLA, for instance, grants credits measured in days of service and requires the customer to request them within 30 days of becoming eligible. That last part matters: unclaimed credits are simply forfeited. Credits are a signal of seriousness, not compensation. No credit ever covered a day of lost billing.
Contract Language Worth Asking About Before You Sign
Bring this list to the conversation. Every item below is a fair question, and a good provider will answer all of them without flinching.
- How is response time measured, and from what moment? Ticket submission, phone pickup, and email receipt are three different starting guns.
- Is response by a human or an automated acknowledgment? An auto reply that says “we got your ticket” should not satisfy a response commitment.
- What is excluded, and who decides? Ask for examples of tickets that fell outside the SLA last quarter.
- What reporting do I get? Monthly numbers on tickets, response times, and SLA compliance should be standard, not something you have to request.
- What happens if you miss repeatedly? Look for an escalation path and a termination right for chronic failure, not just a credit.
- What are the exit terms? Notice period, final invoice, and the handover of documentation and credentials. Ask this before you sign, when you still have leverage.
The Bottom Line
An SLA is not a guarantee that nothing will break. It is a shared definition of what “broken” means, how fast someone starts working, and what happens when the answer is not good enough. The specific numbers matter less than whether they are defined clearly and reported honestly. A provider offering four hour response with plain definitions and monthly reporting is a better partner than one offering fifteen minute response with vague terms and no measurement. When you are evaluating partners, read the SLA alongside the rest of the questions we cover in what to look for in an IT partner.
If you have an agreement in front of you and want a candid read on what it actually promises, send it over. We will tell you what we see, including the parts that are fine. Contact us today.
Sources:
Comments are closed