Ask two managed IT services providers what their service level agreement guarantees and both will answer with the same word: uptime. Put the two documents side by side and you find very different promises, measured in different ways, with different consequences when they are missed.

A managed IT SLA is the only part of a support contract that converts intent into obligation. It sets how quickly someone must reply, what they are committed to fixing, how availability is calculated, and what you are owed when a number is missed. Everything else in a proposal is description. The managed IT SLA is the part you can actually hold a provider to.

This guide works through the three measurements at the centre of every managed IT SLA — response time, resolution time and uptime — along with the priority definitions, measurement rules and exclusions that decide whether those numbers mean anything at all. By the end you will be able to read an agreement and work out what it genuinely commits your provider to doing.

Table of contents

What a Managed IT SLA Actually Commits To

managed it sla guide b priority tier stack

Most buyers meet the document as a page of tables near the back of a contract. It deserves more attention than that, because it is the only section written in numbers rather than adjectives.

The difference between a proposal and a managed IT SLA

A proposal describes what a provider does. A managed IT SLA describes what happens if they do not do it. The first is marketing, the second is enforceable. When a sales conversation promises “rapid response” or “proactive monitoring“, the only question that matters is whether those words appear anywhere in the agreement attached to a target, a measurement method and a remedy.

The four components every managed IT SLA contains

A complete agreement has four moving parts: the services in scope, the targets attached to each one, the method used to measure them, and the remedy when a target is missed. Remove any one of the four and the rest stops working. Targets without measurement cannot be proven, and measurement without a remedy gives a provider no reason to care about the result.

Why definitions matter more than targets

Two providers can both offer a fifteen-minute response and mean entirely different things. One starts the clock when the ticket arrives, the other when an engineer opens it. One counts an automated acknowledgement, the other requires a human. The definitions section of a managed IT SLA is where the real commitment lives, and it is the section almost everyone skips on the way to the numbers.

What a managed IT SLA does not cover

An agreement governs how support is delivered, not how much of it you get. It says nothing about the quality of advice, the seniority of the engineers, or whether the same fault recurs monthly. A managed IT SLA is a floor beneath the relationship rather than a description of it, which is why a strong document and a poor provider can coexist perfectly comfortably.

Response Time: The Clock That Starts First

managed it sla guide c twin dials connected

Response time is the most quoted and least understood measurement in the industry. It is also the easiest for a provider to hit without doing anything useful.

How response time is defined

Response time measures the gap between a ticket being raised and the provider making meaningful contact about it. In a well-written managed IT SLA the definition names the trigger event, the acceptable channels, and what qualifies as contact. In a poorly written one it says “we will respond promptly”, which commits the provider to nothing measurable and leaves you with no basis to complain.

Typical response time targets in the UK market

Across the UK market in 2026, a critical incident usually carries a fifteen to thirty minute target, a high-priority issue one to two hours, a medium issue four business hours, and a low-priority request one business day. A managed IT SLA offering materially faster numbers than these is either staffed unusually well or measuring something different from what you assume.

What actually counts as a response

This is where most agreements quietly disappoint. An automated ticket confirmation counts as a response under a surprising number of contracts. So does a message asking you to restart the machine. Insist that your managed IT SLA defines a response as contact from a person who has read the ticket and can begin diagnosis, otherwise the target measures the speed of the email server rather than the support desk.

Where response time targets mislead

A provider can meet every response target and still leave you broken for a week. Fast acknowledgement is a good sign of a well-run desk, but on its own it measures reception rather than repair. Treat response time as the first of three numbers in a managed IT SLA, never as the headline, and be suspicious of any proposal that leads with it and goes quiet afterwards.

Resolution Time: The Promise Most Providers Avoid

managed it sla guide d curved uptime gauge

If response time is the number providers advertise, resolution time is the one they hedge. It is also the number your business actually experiences.

What resolution time means in a managed IT SLA

Resolution time measures how long a fault takes to be fixed, from the moment it is raised to the moment normal service returns. Some agreements distinguish resolution from a workaround, where a temporary route restores service while the underlying cause remains open. That distinction is worth arguing about, because a workaround that lasts three months is not a resolution by any reasonable reading.

Why providers resist committing to fix times

The resistance is often legitimate. A provider cannot honestly promise a four-hour fix for a fault inside a vendor’s cloud platform or a failed circuit belonging to a carrier. What a good managed IT SLA does instead is commit to fix times for what the provider genuinely controls, and commit to defined escalation and communication intervals for everything else. Vagueness across the board is the warning sign, not caution in specific areas.

Target fix times versus guaranteed fix times

Read the verb carefully. “Target resolution” is an aspiration with no remedy attached. “Guaranteed resolution” carries service credits when it is missed. Most managed IT SLA documents use the first phrasing for everything, which is reasonable for third-party faults and far less reasonable for a failed backup or an unresponsive helpdesk queue that sits entirely inside the provider’s own estate.

How to get a resolution commitment that means something

Ask for guaranteed fix times on the small number of scenarios that would genuinely hurt: total loss of email, a downed line-of-business application, a failed restore. Accept target times elsewhere. A provider willing to write three or four guaranteed resolutions into a managed IT SLA is telling you something real about their confidence, and the negotiation itself reveals which parts of the service they actually trust.

Uptime: What 99.9 Per Cent Really Means

managed it sla guide e broken chain link

Uptime is the number that looks the most scientific and is the most frequently misread. The percentage only means something once you know the window it is measured across and the systems it applies to.

Translating uptime percentages into minutes

Percentages hide their consequences. Across a thirty-day month, 99 per cent uptime permits around seven hours of downtime, 99.9 per cent permits about forty-three minutes, and 99.99 per cent permits roughly four minutes. When a managed IT SLA quotes a figure, convert it into minutes immediately. The difference between two decimal places is the difference between an inconvenience and a working day lost.

What the uptime figure actually covers

An uptime commitment applies to named systems, not to your business as a whole. A provider may guarantee availability of the servers and network they manage while excluding your internet circuit, your cloud applications and anything hosted elsewhere. Check which components the percentage in your managed IT SLA is attached to, because a guarantee covering only infrastructure inside a single rack is far narrower than it first appears.

Planned maintenance and the excluded window

Almost every agreement excludes planned maintenance from the uptime calculation, which is reasonable in principle and abused in practice. The protection you want is a limit: a maximum number of maintenance hours per month, a minimum notice period, and a requirement that the work happens outside business hours. Without those limits, a managed IT SLA can report perfect availability during a month in which staff repeatedly could not work.

Availability versus performance

A system can be technically available and practically unusable. Uptime measures whether something responds, not whether it responds quickly enough to do a job. If performance matters — a database that must return results in seconds, a line that must carry voice traffic cleanly — ask for a performance threshold alongside availability, because a managed IT SLA built on availability alone treats a crawling system as a working one.

Priority Levels: How Severity Gets Decided

managed it sla guide f lens over tile grid

Every target in the document hangs off a priority level. Get the priority definitions wrong and the finest response times in the market apply to the wrong tickets.

The standard four-tier model

Most agreements use four tiers. Priority one covers a total outage affecting the whole business, priority two a major fault affecting a department or a critical function, priority three a single-user problem with a workaround available, and priority four a request or a minor annoyance. A managed IT SLA should spell out each tier with concrete examples drawn from your environment rather than generic descriptions.

Who assigns the priority

This single clause decides how the whole agreement behaves. If the provider assigns priority unilaterally, incidents drift downwards into slower tiers during busy weeks. If you assign it, everything becomes a priority one within a month. The workable arrangement written into a good managed IT SLA is that the customer proposes, the provider may challenge with a stated reason, and unresolved disagreements escalate to a named manager.

Business impact versus technical severity

A failed printer is technically trivial and, in a dispatch warehouse at four o’clock, genuinely critical. Priority definitions built purely on technical severity always misclassify these cases. The fix is to write impact into the definitions: number of users affected, whether revenue-generating work stops, whether a regulatory deadline is at risk. Those criteria make a managed IT SLA describe your business rather than a generic template.

Escalation and priority review

Tickets change importance over time. A minor issue that has been open for a fortnight is no longer minor. Ask for an automatic escalation rule — a ticket that exceeds a defined age moves up a tier and gains a named owner — and check that your managed IT SLA states who is notified at each stage, with contact routes that work outside the ticket portal.

Service Hours, Coverage and the Small Print

Targets only apply during covered hours. A two-hour response at five past six on a Friday evening can mean Monday morning.

Business hours, extended hours and round-the-clock cover

Standard cover typically runs 08:00 to 18:00 on weekdays. Extended cover stretches into evenings and Saturdays, and full round-the-clock cover applies the same targets at every hour of the year. The step up in cost between these tiers is significant, so match the level to genuine operating patterns rather than to anxiety, and confirm which tier each target in your managed IT SLA belongs to.

How out-of-hours cover is actually staffed

There is a large difference between an engineer on a rota, a shared on-call pool, and an overseas desk with no access to your documentation. All three can be described as 24/7 in a proposal. Ask how many engineers are on call, what they can access at three in the morning, and whether the out-of-hours targets in the managed IT SLA differ from the daytime ones.

Holidays, weekends and seasonal peaks

Check how public holidays are treated, because a four-business-hour target crossing a bank holiday weekend can legitimately mean four days. If your business trades through those periods, that assumption needs correcting in writing. Retailers, hospitality and logistics operators should push their peak season into the covered hours schedule instead of discovering the gap during the busiest fortnight of the year.

Measurement: Who Counts, and From When

An unmeasured target is a sentiment. The measurement clauses decide whether the rest of the agreement can ever be enforced.

The ticketing system is the evidence

Every number in a managed IT SLA is calculated from the provider’s own ticketing system, which means the way tickets are logged determines the reported result. Agree that all requests are logged regardless of channel, that a phone call becomes a ticket, and that you have read access to the raw queue rather than only to a monthly summary produced from it.

When the clock stops

Most agreements pause the clock while a ticket waits on the customer or on a third party. That is fair, but it is also the most commonly abused mechanism in the document. Require that every pause is recorded with a timestamp and a reason, that the customer is notified when a ticket is placed on hold, and that a managed IT SLA report shows both elapsed and measured time.

Reporting frequency and transparency

Monthly reporting is the norm and should arrive without being requested. A useful report shows performance against each target, the number of breaches, the cause of each one and any credits due. If a provider will not commit to that format in the managed IT SLA, assume the numbers will only ever appear when they are flattering, which defeats the purpose of measuring them.

Service Credits and What Happens When Targets Are Missed

A target without a consequence is a preference. Service credits are the mechanism that gives the rest of the agreement its teeth.

How service credits are calculated

Credits are usually expressed as a percentage of the monthly fee, rising with the severity and frequency of the breach — perhaps five per cent for a missed priority-one response, ten per cent for an uptime failure, with a monthly cap somewhere between ten and thirty per cent. Check that the percentage applies to the whole fee rather than to the single affected service, which quietly shrinks every remedy in the managed IT SLA.

Caps, claim windows and why credits go unclaimed

Most credits are never paid, because most agreements require the customer to claim them within a short window — often thirty days — and almost nobody tracks performance closely enough to notice. Negotiate automatic application of credits against the next invoice. A provider confident in their delivery rarely objects, and their reaction to the request tells you how often they expect their managed IT SLA to be breached.

Repeat failure and termination rights

Credits handle isolated misses. Persistent failure needs a different remedy, and the right one is an exit. Ask for a clause allowing termination without penalty after a defined pattern of breaches — for example, three consecutive months below target on the same measure. This is the single most valuable clause in a managed IT SLA and the one most often absent from a standard template.

Why credits are not compensation

Be clear about what a credit represents. Five per cent of a monthly fee does not begin to cover a day of lost trading, and no realistic managed IT SLA will. Credits exist to create an incentive and to signal seriousness, not to indemnify you. Genuine financial protection against downtime comes from business interruption cover and from architecture, not from a support contract.

Exclusions That Quietly Void a Managed IT SLA

The exclusions list determines how much of the agreement survives contact with a real incident. It repays a slow, careful reading.

Third-party and carrier dependencies

Providers exclude faults inside systems they do not control, which is fair. What is not fair is excluding them and then doing nothing. The reasonable position, and one worth writing into a managed IT SLA, is that third-party faults are excluded from resolution targets but remain fully inside response, escalation and communication targets, with the provider owning the vendor relationship throughout the incident.

Ageing hardware and unsupported software

Almost every agreement excludes equipment beyond its supported life and software past end of support. This is legitimate, and it is also a slow trap: an estate ages quietly until much of it sits outside the terms. Ask the provider to flag assets approaching exclusion in the monthly report, so the coverage in your managed IT SLA erodes visibly rather than silently.

Customer-caused delays and unapproved changes

Unauthorised changes, undocumented equipment and unavailable staff all suspend obligations. These clauses are reasonable but need boundaries. Define what approval means, keep an agreed change log, and make sure a single unreachable contact at eight in the evening cannot invalidate an entire priority-one incident under the terms of the managed IT SLA you signed.

How to Read and Compare Managed IT SLA Documents

Comparing agreements looks harder than it is. The work is in normalising them before you look at any numbers.

Read the definitions section first

Start at the definitions and read them before the tables. Response, resolution, downtime, business hours and priority all carry provider-specific meanings, and the tables are meaningless until you know them. Reading a managed IT SLA in this order takes twenty minutes and prevents the most common procurement error: comparing two numbers that measure different things and choosing the more optimistic one.

Normalise before you compare

Build a single sheet with a row for each measure and a column for each provider, converting everything to common units. Turn uptime percentages into minutes, express all response times in clock hours with the covered window noted, and mark each resolution figure as target or guaranteed. Differences between managed IT SLA documents that were invisible in prose become obvious the moment they share a table.

Test each target against a real incident

Take an incident you actually had last year and walk it through each agreement line by line. When would the clock have started, what priority would it have carried, when would it have paused, what would have been owed. This exercise finds more weaknesses in a managed IT SLA than any amount of reading, and it gives you specific, concrete questions to put to each provider.

Ask for twelve months of performance data

Any provider that measures itself properly can produce anonymised performance data against its own targets. Ask for the last twelve months: attainment per measure, number of breaches, credits paid. A provider that cannot produce it is not measuring the managed IT SLA it is selling you, and one that produces perfect figures across every month deserves a question about how breaches are recorded.

Reviewing and Renegotiating Your Managed IT SLA

An agreement written for the business you were three years ago will not describe the business you are now. Review it deliberately rather than at the point of a crisis.

When to review

Review annually as a minimum, and immediately after any structural change — a new site, a major system migration, a shift to shift-based or round-the-clock operating. A single serious incident is also a legitimate trigger. If your managed IT SLA performed poorly during a real outage, that is evidence, and the weeks afterwards are the moment when a provider is most willing to improve terms.

What to renegotiate first

Definitions before numbers, every time. Tightening what counts as a response, narrowing the pause rules and adding impact criteria to the priority tiers will improve your service more than shaving ten minutes off a headline target. Once the definitions in the managed IT SLA are sound, the remaining conversation about targets and credits becomes far more straightforward for both sides.

Making the review a working meeting

Bring the last twelve reports, your own ticket records and a list of incidents where the experience did not match the numbers. The gap between reported and experienced performance is the most useful thing in the room. A provider that engages seriously with that gap is worth keeping; one that defends the report against your lived experience has told you what the next renewal will be like.

Frequently Asked Questions About Managed IT SLAs

The same questions come up in nearly every procurement conversation. Short answers to each follow.

What is a good response time for a managed IT SLA?

For a critical, business-wide outage, fifteen to thirty minutes during covered hours is the competitive standard in the UK. Anything under fifteen minutes usually means an automated acknowledgement is being counted. What matters more than the number is the definition sitting behind it and whether the same target applies outside business hours or only during the working day.

Is 99.9 per cent uptime good enough?

For most small and mid-sized businesses, yes. It permits roughly forty-three minutes of unplanned downtime per month, which is tolerable for typical office operations. It is not good enough for e-commerce, manufacturing lines or clinical systems, where 99.95 or 99.99 per cent is appropriate — and where the managed IT SLA needs redundancy in the design, not just a higher number in the table.

Should a managed IT SLA guarantee resolution times?

For faults inside the provider’s control, yes, at least for the highest priority tiers. For faults inside a third-party cloud platform or a telecoms carrier, guaranteed fixes are not realistic and a provider promising them is overselling. The workable middle ground is guaranteed resolution on a defined list of critical scenarios and committed escalation intervals everywhere else.

What happens if the provider misses the targets?

Whatever the remedies section says, which in most cases means service credits against the following invoice, provided a claim is made in time. Persistent breaches should trigger a documented improvement plan and, past a defined threshold, a right to terminate without penalty. If your managed IT SLA contains no remedy at all, the targets in it are advisory rather than contractual.

Can a managed IT SLA be customised?

Yes, more readily than most buyers assume. Providers run standard tiers because they are efficient, but definitions, priority criteria, covered hours and credit mechanics are all routinely adjusted for a customer who asks specifically. Broad requests to “improve the SLA” go nowhere; a marked-up document with four precise changes usually produces a serious response within a week.

Getting Your Managed IT SLA Right

The difference between a strong agreement and a weak one rarely shows up on a good month. It shows up on the worst day of the year, which is precisely the day it was written for.

Prioritise definitions over headline numbers

Spend your negotiating effort on what the words mean rather than on the digits in the table. A fifteen-minute response defined as human contact from an engineer who has read the ticket is worth far more than a five-minute response satisfied by an automated email. Every managed IT SLA that disappointed someone did so through its definitions, not its targets.

Insist on reporting you can actually check

Ask for raw ticket access alongside the monthly summary, and reconcile the two occasionally. A provider that reports honestly against its own targets, including the months it missed them, is demonstrating something no proposal can. Reporting you can verify turns a managed IT SLA from a document filed after signature into a live measure of the relationship.

Treat the agreement as a living document

Put the review in the calendar rather than waiting for a renewal notice or an outage. Businesses change shape faster than contracts do, and a managed IT SLA that is revisited each year stays aligned with how the business actually operates. Signed once and forgotten, it slowly becomes a description of a company that no longer exists.