SLA IT: what is the difference between response time and repair time

Two offers, two numbers. The first promises a response in 15 minutes, the second in 4 hours. The choice seems obvious, until email stops working on Wednesday at nine in the morning and it turns out that those 15 minutes mean an automatic acknowledgement that the ticket was received, while the technician only starts work in the afternoon.

Shortcut SLA stands for Service Level Agreement, i.e. the service level agreement. Buyers usually read it as a promise of quick repair. This misunderstanding then costs months of frustration on both sides, because the supplier formally respects the terms and the customer feels cheated. They're both right because they're talking about two different things.

SLA is not a promise that every failure can be fixed in an hour. It is a description of how quickly someone will deal with a report, in what order, who decides, when the case moves up and how it will all be measured. In other words: SLA IT buys predictability, not speed.

This material explains the mechanics, not the deal. All numbers are illustrative examples and are not values ​​to which NexaIT or any other provider commits.

What exactly does SLA measure?

Let's start by sorting out three terms that are sometimes used interchangeably in sales conversations, although they mean different things.

SLA is a contractual obligation: the level of service to which the provider commits, usually with consequences of failure to comply. SLO is an internal goal set by the supplier; it can be more severe than SLA because it gives a margin. KPI is a meter that is measured by quality; in itself it is not a commitment.

This has practical significance when reading offers. Sentence "our average response time is 12 minutes" describes a KPI for a period, not a liability. Last quarter's average says nothing about what will happen to your report on Friday at 4:50 p.m.

SLA in IT services usually consists of several independent elements:

• Response time: how long will the supplier take action after the notification has been accepted.
• Bypass time: After which time it will restore action, even if it is temporary.
• Resolution time: how long until it removes the cause?
• Service hours: the window in which these times run at all.
• Availability: what percentage of service time is to operate.
• Priorities: how applications are classified and who decides.

Accessibility requires a separate comment, because it is the most frequently confused parameter. Availability record 99,9% per month allows approx 43 minutes unavailability (30 days × 24 h × 60 min × 0.1% = 43.2 minutes). Ale to parametr services, usually a specific system or link, and not a commitment to repair any failure in 43 minutes. Availability and repair time are two different promises about two different things.

Response, diagnosis, workaround and solution

One report goes through four stages. Confusing them is the source of most SLA arguments.

Response. Someone takes over the report and starts working on it. Beware of the trap: automatic message “We accepted your application, number 4417” It is not a response; it is a confirmation of registration. If the offer boasts of a response in a minute, it is worth asking whether it is a man or a script. The measure of this stage is MTTA, which is the average time to submit a notification.

Diagnosis. Determining what actually happened and how widespread the problem is. This stage can be the longest and most difficult to commit to time, because it is impossible to know in advance whether the cause is a broken cable or a failure at the operator's.

Bypass. Restore operation without removing the cause. The accounting printer is down, but documents can be printed on the device next to it. The application server is not up, but users are working on a backup instance. The company is operational, the problem still exists.

Solution. Eliminate the cause. New printer, repaired server, replaced switch.

The separation of the bypass from the solution is crucial for two reasons. First of all, it's usually the bypass that counts for the company: the moment when people go back to work. Secondly, this is the most common place of abuse in reports: the supplier closes the report at the bypass stage and shows a great solution time. Formal failure "dissolved", in fact the company is working on a makeshift basis and the cause is waiting for repetition.

A well-constructed SLA describes both times separately and requires that the ticket remains open until the cause is corrected, even if at a lower priority. It is the measure of the whole MTTR, i.e. the average time to restore the service; this value only makes sense if you know whether it measures a workaround or a solution.

Priorities P1-P4 with examples

Priority is not a judgment of how upset someone is. It should result from two variables: impact (how many people and processes affected) and urgency (can you wait).

The table below is an educational example showing typical classification logic. Specific definitions and times always result from the contract with a given supplier.

Priority	When	Example	Typical wait
P1 (critical)	Revenue-producing activity or process stopped	The ERP server is not working, the entire company is not issuing documents. Link failure in the only location. Suspected ransomware attack	Immediate start, continuous operation, bypass priority over solution
P2 (high)	Serious obstruction or workaround exists or affects part of the company	Mail in one department is not working. Label printer failure on one line when the other is on	Pick-up within a short agreed time during service hours
P3 (normal)	Single user, work is possible	Slow computer. Problem with one application for one person	Take within a standard window
P4 (low)	Request, change, inquiry	New position in two weeks. Requesting additional permissions	Planned implementation, within the agreed date

Three things are worth determining when signing the contract.

Who assigns priority. If only the supplier does so, he has a built-in incentive to undercut, because the lower priority is a looser counter. If only a customer, everything will be critical within a month. Reasonable model: the client proposes, the supplier can change with justification, and the client has a recourse path to the designated person.

That the priority may change. Report starts as P3 "app is slow", and after diagnosis it turns out P1 "matrix disk is falling apart". The contract should allow for escalation and recalculation of the meter.

That P1 costs. UK Guidelines National Cyber Security Centre (published 24/11/2025, reviewed 24/06/2026) draw attention to something that is easy to miss in negotiations: faster response increases the cost of the contract. You can't have a one-hour response at a daily rate. If an offer promises one thing for the price of another, something else has been cut out of it.

When it runs and when time stops

This is where most of the real misunderstandings live. The number in the offer itself means nothing unless you know how it is calculated.

From when the counter starts. From the moment the user submits the ticket, or from when it is registered in the provider's system? For a phone call at 8:58 when support starts at 9:00, the difference can matter. Common rule: the counter starts when the notification is received through the channel described in the contract.

And this is the answer to the question why the reporting channel matters. A problem reported via text message to a technician you happen to know usually does not trigger any counter because it does not enter the system.

Service hours. This determines the actual waiting time more than the number itself. Four hours of response time in window 8:00-16:00 means that the 3:30 notification may wait until 11:30 the following day, and formally the SLA will be kept. Same "4 hour response" in 24/7 mode is a completely different service and a different price.

It is also worth determining what happens on weekends and holidays and whether there is a separate mode for critical failures outside of hours. Many contracts provide for an on-call mode for P1 with a standard window for the rest.

What stops the counter. A pause is warranted when a case is waiting for something the provider does not control. Typical cases:

• waiting for customer information or decision;
• waiting for access to a room or device;
• waiting for parts delivery;
• waiting for a response from the software manufacturer;
• waiting for the failure to be removed by the link operator;
• scheduled service window.

A rule that protects both sides: there must be a pause visible in the reporting system along with the reason and time. A counter stopped silently and discovered in the monthly report destroys trust more effectively than exceeded SLAs.

Service windows. Scheduled work should not count towards unavailability provided it is announced in advance as agreed. Without this caveat "planned maintenance" becomes a convenient bag for everything.

Customer and supplier dependencies

SLA is a two-way commitment, although offers rarely emphasize this. The supplier is responsible for what he has control over, and only that.

NCSC indicates in the cited guidelines that the contract should clearly specify what the supplier is responsible for and what remains with the customer. In the context of SLA, this means writing down the customer's responsibilities:

• reporting problems via established channel;
• providing access to rooms and equipment;
• identification of the decision-maker and his availability;
• making purchasing decisions within a reasonable time;
• not making changes to the environment beyond the supplier's knowledge.

This last point can be the source of the most bitter arguments. If someone in the company reconfigures the router on his own, the provider is responsible for the consequences to the extent that he knows about the change.

A separate category includes dependencies on third parties: Connectors, software manufacturers, hardware services. The IT provider will not repair the fibre dug through the excavator. It can report a malfunction, escalate and guard, but it is not responsible for the resolution time. The deal should call it, and the report should show separately.

This is not an excuse from the supplier, just a condition of SLA fairness. Committing to things you can't control is either unfair or included in the price as a risk, and then you pay for them in a subscription.

It is worth asking about the supplier's subcontractors. The NCSC recommends a supply chain risk assessment and indicates that the contract should include liability for third parties used to provide the service.

SLA report for management

The report, which is a list of closed tickets, is not an SLA report. The board is not interested that 47 tickets have been closed. It is interested in whether the company is stable and what's threatening next quarter.

Useful monthly report answers five questions:

1. How many reports were there by priority? and how it looks compared to previous months. A growing P1 number is a signal that something is structurally breaking down.
2. Whether the SLA was met: with a separate indication of the cases of overrun and their causes. A report without a single overshoot for a year is suspicious, not good.
3. How long the counter was stopped and why. This shows where the process hangs on the client side.
4. What is repeated. Five reports per month about the same printer is not five incidents, but one unresolved problem.
5. Which requires decisions and money. Hardware without support, expiring licences, identified risks.

It's worth asking for a sample report before signing the contract. This is one of the best tests of supplier maturity: the company that has the process will show the anonymized document without hesitation.

How to compare offers

Putting numbers together leads you astray. The following list of questions reduces the offers to a common denominator:

• Is the number given for a response, workaround or resolution?
• Does the response mean human action or automatic confirmation?
• What are service hours and how is time outside of them counted?
• Who assigns priority and how can I appeal?
• What stops the counter and are pauses visible in the system?
• Can a ticket be closed in a bypass?
• What does availability cover, if declared?
• Which elements depend on third parties and how are they billed?
• What happens when SLA is not met?
• What does the report look like?

For the sake of order, the NCSC guidelines quoted give indicative values: a response below an hour for urgent matters, one working day for minor cases and two-three working days for routine cases. These are guidelines developed for the UK market, not the norm in force in Poland. It is not worth considering them as a measure to be applied to Polish offers; it is worth considering as a reference point, when the offer deviates from them very strongly in any direction, and then ask why.

Common Rule of Thumb: an offer with worse numbers and clear rules is usually better than an offer with better numbers without rules. The first one is enforceable, the second one is not.

Sample incident axis

The following example is an illustration of the mechanism, not a description of an actual event or a declaration of times. We assume a hypothetical contract with service hours 8:00-17:00 and response to P1 up to 1 hour.

Time	Event	Meter reading
9:12	The user reports through the system: ERP is not working, the entire company is at a standstill	Start. The report has been received
9:18	Supplier classifies as P1, takes over the notification, contacts the company	Response: 6 minutes. Kept
9:20-10:05	Diagnosis: the database is working, the application is not responding, the cause is a full disk on the server	Running
10:05	Workaround: free space, restart service, ERP works	Bypass: 53 minutes from reporting. The company is working
10:10	Report remains open, cause not resolved, priority downgraded to P2	Running for a solution
10:30	Analysis: disk is full of application logs, no rotation. A decision on expansion is needed	Running
11:00	The supplier presents two variants and asks for a decision	Pause: Customer waiting, visible in the system
14:40	The customer accepts the variant	Reissue
15:30	Implementation of log rotation, disk occupancy monitoring	Running
16:10	Solution: cause removed, prevention from repetition	Solution: 3 h 18 min working time (without pause)

Three observations from this axis. First, the company was back up and running after 53 minutes, even though the problem had been resolved after 4 p.m., and it was the workaround, not the solution, that mattered to the company. Secondly, there was a pause on the client's side for almost four hours; if the counter was running, the supplier would have exceeded the SLA for someone else's delay. Thirdly, if the report had been closed at 10:05 on the bypass, the statistics would have been better and the disk would have been full again in a month.

SLA buys predictability, not speed

The most important question when reading the offer is not "how many minutes", but "what exactly do you measure and how do you count it?" A provider who can describe the meter rules, pauses, escalation path, and how to report likely has a process behind it. The one who only gives a flashy number sells an impression.

If you are comparing offers and want to discuss what these principles would look like in your processes, let's talk about the priorities for your company. We start by determining which systems retain revenue, because the sensible classification of reports depends on them. The scope of permanent care is described on the website IT outsourcing.

---

Disclaimer

This material is informative and explains the mechanics of service level agreements. All numerical values ​​in the examples are for illustration purposes only and do not constitute an offer or commitment. Assessment of SLA provisions in a specific contract, including the consequences of failing to meet them, requires consultation with a legal advisor.

Sources

• National Cyber Security Centre, Choosing a Managed Service Provider (MSP), published 24/11/2025, reviewed 24/06/2026, https://www.ncsc.gov.uk/guidance/choosing-a-managed-service-provider-msp (accessed 16/07/2026)

As of July 16, 2026