Support SLAs Explained: Response Times, Priorities and Scope

A support SLA looks reassuring on its first page: a table of priorities with short times beside them. Whether it protects you depends on the definitions under that table, and that is where two offers that look identical turn out to be far apart.

This guide goes through the clauses that change the outcome when something breaks, then gives you a list for comparing offers side by side. It describes how these agreements work in general. The terms of any particular provider, ours included, are whatever that provider's contract says.

Response time is not resolution time

A service level agreement, in the words of the NIST glossary, sets out the provider's responsibilities and the customer's expectations. For support, those expectations hang on four different moments, and an SLA may commit to only one of them:

• Acknowledgement: the ticket has been received. This is often automatic.
• Response: a person able to work on the problem has looked at it and replied.
• Restoration or workaround: the service is usable again, perhaps by a temporary measure such as rolling back a release or switching a feature off.
• Resolution: the underlying cause has been fixed.

Many support agreements commit to response time alone, for an honest reason: nobody can promise how long an unknown fault will take to repair. It does mean that a short time in the table tells you when someone starts, not when the site is back.

So check what counts as a response (an automated reply should not), whether the top severity also has a restoration target, how often you will be updated while an incident is open, and whether the times are described as targets or as commitments with a consequence attached.

Severity levels decide which clock applies

Every time in an SLA belongs to a severity or priority level. The labels vary, but most agreements use four levels that look something like this:

Level	Typical definition	Example
Critical	The service is down or unusable for all or most users, with no workaround	The site is offline, or checkout fails for everyone
High	A major function is broken or badly degraded, and any workaround is poor	Password reset emails are not sent, or one payment method fails
Normal	A fault with limited impact, or one with an acceptable workaround	A report exports the wrong column, or a layout breaks in one browser
Low	Cosmetic problems and general queries	A typo, or a "how do I" request

The definitions matter more than the times. Read who assigns the level, who is allowed to change it, and what happens when you disagree. Many support teams derive priority from two factors, impact (how many people are affected) and urgency (how soon it hurts), an approach that comes from the ITIL service management framework. Wording such as "significant business impact" invites an argument mid-incident. Good definitions rest on things that can be counted: all users or some, a workaround or none.

Check too whether change requests share this scheme or go to a separate queue with its own turnaround and billing.

Hours of cover and how the clock runs

The cover window says when the clock is allowed to run: business hours, extended hours or all day every day. Look for the time zone and for whose public holidays apply. A one-hour response during business hours eight time zones away from your customers is a different product from the same promise in your own working day.

Next find the event that starts the clock. It is normally a ticket logged through a named channel, such as the support portal, the support address or a phone line reserved for critical faults. A message to a developer's personal chat usually does not count.

The clock can also pause. Most agreements stop it while the provider waits for you to supply information, access or approval, and often while a third party is working. That is fair, as long as the pause is recorded on the ticket where you can see it.

A worked example shows why this arithmetic matters. Take a hypothetical target of four business hours, with cover from 09:00 to 18:00, Monday to Friday. A ticket logged at 17:00 on Friday uses one hour of the target that day. The remaining three run from 09:00 on Monday, so the target is met by a reply at noon. That is 67 hours on the calendar and four on the clock. Nothing is wrong with that, provided you understood it when you signed.

Scope, exclusions and your side of the bargain

Scope should name the systems, by site or application and by environment, and the kind of work: diagnosing and fixing faults in what exists, as opposed to building new features.

The exclusions are just as important. The common ones are:

• faults inside third-party services such as the hosting company, the payment gateway or the email provider, where your supplier can investigate and chase but cannot commit to someone else's repair time;
• problems caused by changes that you or another vendor made;
• software running on versions their makers no longer support;
• data that cannot be recovered from the backups that exist;
• planned maintenance windows, and events outside anyone's control.

Most agreements also place obligations on the customer: providing access, naming a contact who can make decisions, keeping the hosting at a stated minimum and keeping software within supported versions. If those are not met, the times may not apply.

Read the exclusions against your own setup. If you arrange your own hosting and the SLA excludes hosting faults, you need to know who covers that gap.

Uptime percentages and service credits

An uptime commitment usually belongs to hosting and not to support, but the two often share a document. Turn the percentage into minutes before you judge it. Over a 30-day month, a figure of 99.9 allows about 43 minutes of downtime, and 99.5 allows roughly three and a half hours. Then read how it is measured: by whose monitoring, over what period, whether planned maintenance counts, and whether "available" means the home page answers or the application works.

The usual remedy for a missed commitment is a service credit: a part of the monthly fee taken off a later invoice, normally capped, claimed in writing within a set number of days, and often described as the only remedy. A credit will not replace lost sales. Liability and remedy clauses are legal terms, so have your own counsel read them before you sign.

Comparing two support SLAs line by line

Put the offers in columns and fill in the same rows for each:

• which moments carry a committed time: response only, or restoration as well;
• the severity definitions, word for word, and who assigns the level;
• cover hours converted to your time zone, and the holiday calendar;
• the channels that start the clock, and whether critical faults have a phone line;
• the rules for pausing the clock;
• the escalation path, by role, when a target is missed;
• reporting: a regular statement of tickets measured against the targets;
• the hours of work included, and what happens when they run out;
• the exclusions and your obligations;
• the remedy for missed targets, the notice period, and the help you get on exit. Our handover checklist lists what to ask for when a contract ends.

Any row you cannot fill in from the document is something to ask before signing.

How much cover you need

Match the agreement to what an hour of downtime costs you. A brochure site that brings in inquiries during the working week is well served by business-hours cover, and paying for a night shift would be waste. An online store with customers in several time zones, a learning platform with exam deadlines, or an internal system that operations depend on needs someone reachable out of hours for critical faults. A common middle course is business-hours cover for everything, plus an emergency line for the top severity only.

Keep in mind what an SLA cannot do. It governs how fast people react, not how often things break. That depends on the routine work described in what a website maintenance plan should include. When we set up maintenance and support for a client, the cover hours, response targets and scope are agreed for that client and written into the proposal. Ask anyone you are comparing to put theirs in writing in the same form.

Frequently asked questions

What is the difference between an SLA and an SLO?

A service level objective is a target a team sets for itself, such as a response time it aims to meet. A service level agreement is a commitment to a customer, written into a contract, usually with a consequence when it is missed. Providers often run tighter internal objectives than the agreement they sign.

Is a support SLA legally binding?

It is binding to the extent that the contract makes it so. An SLA that the main agreement refers to forms part of that contract, while a page on a website headed "our targets" may not. What you can claim when it is missed depends on the wording and on the law that governs the contract, so ask your counsel.

What response time is reasonable for a critical fault?

There is no standard figure, and the number matters less than its conditions. A short target that applies only in business hours, starts only after a phone call and commits to nothing beyond a first reply can be worth less than a longer one with round-the-clock cover and a restoration target. Compare the whole clause.