What Is an SLA in IT Support? Meaning, Contents and What to Check Before You Sign

The short version: An SLA (service level agreement) is the part of an IT support contract that says how fast the provider must respond and fix problems, during which hours, how that is measured and reported, and what happens when a target is missed. Read it for the numbers and the exclusions, not for the adjectives.

If you are comparing IT support providers, the SLA is the page that turns "we are responsive" into something you can hold them to. It is also the page that is most often skimmed. This guide explains what the term means, what a sound IT support SLA contains, how to read the numbers, and what to check before you sign.

We read the outside definitions on 28 October 2026: the Wikipedia article on service-level agreements, the Wikipedia article on service-level objectives and the Wikipedia article on operational-level agreements (all checked 2026-10-28). Where we describe how Brocent works, the numbers come from our published SLA and service priority page, which we re-read the same day.

What is an SLA, and what does the term mean?

An SLA is a written agreement between a service provider and a customer that defines particular aspects of the service, such as quality, availability and responsibilities, as terms of the contract. That is the sense used in the Wikipedia article on service-level agreements (checked 2026-10-28). In plain terms: the provider says what it will deliver, you say what you expect, and both write down how it will be measured.

Three related terms get mixed up, so it helps to separate them:

• SLA: the whole agreement. It covers scope, hours, targets, reporting, remedies and responsibilities.
• SLO (service level objective): one measurable target inside the SLA, such as "first response to a critical incident within 15 minutes". The Wikipedia article on SLOs (checked 2026-10-28) describes an SLO as a target value or range for a service level, and the SLA as the entire agreement around it.
• SLI (service level indicator): the measurement behind a target, for example "the minutes between a ticket being logged and an engineer replying".

When people search for "sla meaning" in an IT context, they usually want the second and third ideas: what numbers are promised and how those numbers are counted. The rest of this article follows that thread.

What does an IT support SLA actually cover?

A useful IT support SLA covers seven things. If one is missing, ask for it in writing.

1. Scope: which services and which users

The SLA should say what is supported (laptops, servers, Microsoft 365, network, printers, line-of-business apps) and for whom (all staff, named sites, named devices). A target that applies to "IT support" with no scope leaves room for a dispute about whether your problem is covered at all.

2. Service hours

Targets only run inside the service window. The common patterns are business hours (for example Monday to Friday business hours, written 8x5; the number of hours per day varies by provider) and around-the-clock coverage (24x7). Check what happens to a ticket logged at 17:55 on a Friday. Check which public holidays count, and in which city, because a provider that serves several markets may follow a different calendar from yours.

3. Priority definitions

A priority level says how serious an incident is, and it decides which targets apply. Definitions should be based on business impact, not on how loudly someone asks. Our P1 to P4 guide walks through the four-level model, and the companion article on severity versus priority explains how impact and urgency combine into a level.

4. Response and resolution targets

These are the headline numbers, and the next section deals with them in detail.

5. Availability commitments

For hosted services, servers or cloud platforms, the SLA may promise a percentage of uptime. The section on availability percentages below shows the arithmetic.

6. Exclusions and pause conditions

Every SLA has them. Typical ones are planned maintenance, events outside the provider's control, faults in a third party's service, and time spent waiting for the customer. They are legitimate when they are narrow and written clearly. They are a warning sign when they are broad.

7. Reporting, review and remedies

An SLA that nobody measures is a brochure. The agreement should say what is reported, how often, who reviews it, and what happens after a miss. Remedies can be service credits, a root cause review, a remediation plan, or a right to end the contract after repeated misses.

What is the difference between response time and resolution time?

This is the most common confusion, and it is the one that costs customers the most.

• Response time: how quickly the provider acknowledges the ticket and a qualified person starts working on it. It tells you that someone has picked it up.
• Resolution time: how long until the problem is actually fixed or a workaround is in place. It tells you when you can work again.
• Why both matter: a fast response with no resolution target is a promise to reply, not a promise to fix. A resolution target with no response target can leave you waiting in silence until the deadline.

Read each definition for the start and the stop of the clock. A clock that starts when a ticket is logged is different from one that starts when an engineer accepts it. A clock that stops when the engineer replies is different from one that stops when you confirm the fix.

Many SLAs also separate remote support from onsite attendance. Brocent's published table, for example, lists first response, remote support, onsite and resolution as separate columns, so each one has its own target. As of 28 October 2026 the table shows a first response of 15 minutes for P1 and P2 incidents, 30 minutes for P3 and 60 minutes for P4 and P5, and resolution targets of 8, 24, 48, 48 and 72 business hours for P1 to P5. The page also states that targets depend on the service window (8x5 or 24x7) and on the contract terms, which is the right way to read any table like it. Our managed IT support plans and per-user pricing repeats the headline commitment of 15-minute first response on critical incidents.

How do availability percentages translate into downtime?

Availability is stated as a percentage of time a service is up over a period, and small differences in the percentage are large in hours. The arithmetic is simple, and you can do it yourself on any quote.

• 99%: about 87.6 hours of downtime a year, or about 7.2 hours in a 30-day month.
• 99.9%: about 8.76 hours a year, or about 43 minutes in a 30-day month.
• 99.99%: about 52.6 minutes a year, or about 4.3 minutes in a 30-day month.

(These figures follow from a year of 8,760 hours; they are our own arithmetic, not a vendor claim.)

Then ask the questions the percentage hides:

• Is planned maintenance counted as downtime, or excluded?
• Is the measurement over a month, a quarter or a year? A yearly average hides a bad month.
• Who measures it, and can you see the data?
• Does the percentage apply to the whole platform, or to one component?

Availability percentages are most meaningful for infrastructure the provider runs. For a help desk, the equivalent is how quickly people respond and how often problems are fixed.

What are service credits, and are they enough?

A service credit is a reduction in a future invoice when the provider misses a target. Credits show that the target has a consequence, but treat them as a signal, not as compensation. A credit rarely equals the cost of a day of lost work.

Check these points:

• Trigger: which misses earn a credit, and does the customer have to claim it?
• Size: is the credit a fixed amount or a percentage of the monthly fee, and is there a cap?
• Repeat misses: is there an exit right after several misses in a row? This is often worth more than the credit.
• Exclusive remedy: does accepting a credit stop you from raising other claims?

If the SLA has no remedy at all, the targets are aims rather than commitments. Ask the provider what happens in practice when a target is missed, and ask for an example of a root cause review.

How should the SLA be measured and reported?

Targets need evidence. A sound arrangement has these elements:

1. A ticketing system that timestamps every step, so response and resolution are calculated from records, not from memory.
2. A regular report, usually monthly, showing actual performance against each target, by priority.
3. A review meeting or call, where misses are explained and agreed actions are recorded.
4. Access to the underlying data, or at least a clear definition of how each figure was calculated.

Brocent states that managed clients receive written reports, and the homepage shows sample reports with indicators measured against the SLA you signed. Which reports apply depends on your scope. Whichever provider you choose, ask to see a real, anonymised report before you sign. A provider that cannot produce one has probably not been measuring.

Useful report metrics include the share of tickets that met the response target, the share that met the resolution target, the average time to resolve, and how many incidents were reopened. For the definitions of the time-based measures, see our guide to MTTR, MTBF and MTTA. For how often a user's problem is solved at the first contact, see first call resolution.

What does an SLA not guarantee?

An SLA is a promise about speed and process, and it has limits you should know about before you rely on it.

• It does not prevent incidents. A response target says how fast someone starts work after something breaks. Preventing breakage is the job of monitoring, patching and good design, and those belong in the scope section, not in the targets.
• It does not guarantee a fix by the resolution time in every case. Some faults depend on a vendor, a carrier or a spare part. A well-written SLA says how those cases are handled, for example by agreeing a workaround and a revised time.
• It does not replace a relationship. A report full of green figures can still sit beside a team that is slow to explain things. Use the review meeting to ask about patterns, not just totals.
• It is only as good as the priority given to your ticket. If every ticket is logged as critical, the targets lose meaning. If none is, you wait longer than you need to. Agree who sets the priority, and how a disagreement is settled.

A worked example helps. Suppose a file server stops responding at 10:00 on a Tuesday and nobody in the office can open shared documents. Under a four-level model that is a critical incident. The clock for first response starts when the ticket is logged. An engineer acknowledges within the response target and begins diagnosis. If the cause is a failed disk, the team may restore service from a replica or backup while the replacement part is ordered, then record the true fix separately. A sound SLA counts the first as the resolution of the outage and the second as follow-up work, and the monthly report shows both. Ask your provider to walk you through an incident like this one before you sign.

How does an SLA relate to OLAs and underpinning contracts?

Your SLA is with the provider. The provider, in turn, may rely on its own internal teams and on outside suppliers to deliver it. Those arrangements have their own names. An operational-level agreement (OLA) is described in the Wikipedia article on OLAs (checked 2026-10-28) as an agreement that defines the responsibilities and timeframes of internal support groups so that the SLA can be met. A contract with an external supplier that backs a service is called an underpinning contract in ITIL terminology; we describe it in our own words here because we did not retrieve the ITIL glossary text on 28 October 2026.

You do not need to read your provider's OLAs, but you should ask whether they exist and whether the SLA targets are realistic against them. A promise of a 15-minute response is only credible if the team behind it is staffed for that window. The article on SLA, OLA and underpinning contracts sets out how the three fit together.

What should you check before you sign an IT support SLA?

Use this list. It works for any provider, including us.

1. Are response and resolution targets defined separately for every priority?
2. Do the priority definitions describe business impact in words you can apply?
3. Which hours does the clock run, and who decides when it pauses?
4. How is each target measured, and what is the report cadence?
5. What are the exclusions, and are they narrow and specific?
6. What happens after a miss: credit, review, exit right?
7. Is there a named escalation path, with contacts and time limits? See our escalation matrix template.
8. Which support level handles which kind of issue? See L1, L2 and L3 support levels.
9. Can you see a sample report and the actual published targets, not a summary?
10. How often is the SLA reviewed, and what is the change process?

If a provider answers all ten in writing, the SLA is doing its job. If several answers are "it depends" with no further detail, the SLA is carrying more risk for you than it appears to.

How does Brocent publish its SLA?

Brocent publishes its targets openly on the SLA and service priority page: five priority levels (P1 to P5), with first response, remote support, onsite and resolution targets for each, two service windows (8x5 standard and 24x7 premium), an impact-by-urgency matrix that the service desk applies when triaging tickets, and four categories of system change. The same page notes that the figures depend on the service window and the contract terms.

Our managed IT support plans describes how the SLA fits into a managed IT arrangement, and the 24/7 help desk service covers round-the-clock coverage. Plan prices and the published SLA sit side by side on the managed IT support plans and per-user pricing, so you can compare them before you talk to anyone.

Frequently asked questions

What does SLA stand for in IT?

SLA stands for service level agreement. In IT support it is the part of the contract that sets the service hours, the response and resolution targets, how they are measured and reported, and what happens when a target is missed.

What is the difference between an SLA and a contract?

The SLA is usually a schedule or section within the contract. The contract covers price, term, liability and termination; the SLA covers the quality and speed of service. Some providers publish the SLA separately, as Brocent does, and refer to it in the contract.

What is a good response time for IT support?

It depends on priority and service hours. A critical incident should have a response measured in minutes and a lower-priority request in hours, with clear rules on when the clock runs. Compare the published targets by priority level instead of comparing one headline number. Our P1 to P4 guide explains the usual structure.

Is response time the same as resolution time?

No. Response time is when the provider acknowledges and starts work on the ticket. Resolution time is when the problem is fixed or a workaround is in place. A good SLA states both for every priority.

What happens if the provider misses the SLA?

It depends on the wording. Typical remedies are a service credit against a future invoice, a root cause review, a remediation plan, and in some contracts a right to end the agreement after repeated misses. If the SLA names no remedy, ask what the provider does in practice.

Does 99.9% availability mean the service is down for 43 minutes a month?

On a 30-day month, 99.9% allows about 43 minutes of downtime, and across a year about 8.76 hours. Check whether planned maintenance is excluded and whether the figure is averaged over a month, a quarter or a year.

Should a small business care about the SLA if it only has a few staff?

Yes. A small team has less spare capacity, so a long wait for a fix costs a larger share of the working day. A short, clear SLA with realistic targets and a monthly report is more useful to a small business than a long one nobody reads.

If you want to compare your current SLA against what we publish, or you would like a second opinion on a draft, contact us.

Want these targets in a contract, not a slide? Brocent's managed IT support plans publish the SLA and the per-user monthly price side by side for Hong Kong, Singapore, mainland China and the United States. See the plans and pricing or talk to a consultant.