WAN-SLA and MTTR: What Really Counts in the Contract

WAN-SLA: more than a percentage

What a WAN-SLA must deliver

Almost every quote for site connectivity states an availability of 99.9 percent or more. That figure alone says little about how well your network really runs day to day and during an incident. What matters is what stands next to it in the SLA.

Auf den Punkt gebracht:

  • Read availability correctly: 99.9 percent means around 8.8 hours of downtime per year, 99.99 percent only about 52 minutes
  • Metrics over percentages: latency, jitter and packet loss decide the real application quality, not availability alone
  • MTTR is the lever: the guaranteed repair time determines how long a site is really offline during an incident
  • Check penalties: without service credits and a clear trigger, any SLA promise stays consequence-free

Die Lösung: Check an SLA vendor-neutrally along the metrics that matter in operation, and bundle the individual commitments into ONE unified SLA with ONE point of contact.

Worum es in diesem Beitrag geht: What a WAN-SLA must really deliver, how to read availability correctly, which metrics matter in operation, why MTTR is often more important than the percentage, and what to watch for with penalties.










What is a WAN-SLA really?

A WAN-SLA is the contractual commitment to the quality of your site connectivity, not just a marketing figure on the quote. It defines in measurable terms which availability, latency, jitter, packet loss and repair time the provider guarantees, and what happens if it misses those values.

The decisive difference lies in the detail. Two providers can both promise 99.9 percent availability and still deliver completely different service, depending on how and where it is measured and how quickly incidents are resolved.

A solid SLA therefore always names three things: the committed values, the measurement method including measurement points, and the financial consequence of non-compliance. If one of these building blocks is missing, the promise is worth little when it counts.

Availability: why 99.9 is not always 99.9

Availability sounds unambiguous, but it is not. Each additional nine drastically shortens the permitted downtime, as the following table shows.

AvailabilityMax. downtime per yearMax. downtime per month
99.0 %approx. 3.65 daysapprox. 7.3 hours
99.9 %approx. 8.8 hoursapprox. 43.8 minutes
99.99 %approx. 52.6 minutesapprox. 4.4 minutes
99.999 %approx. 5.3 minutesapprox. 26 seconds
Calculated downtime per availability class. Values rounded.

For a critical site, the difference between 99.9 and 99.99 percent is considerable: a good 8.8 hours versus just under 53 minutes of downtime per year. Equally important is the question of what counts as an outage at all. Are planned maintenance windows excluded? Does a partial fault with reduced bandwidth count? Is the average taken per site or across the entire network?

SAVECALL checks these definitions across providers and makes them comparable. For your sites we bundle the individual commitments into ONE unified SLA with ONE point of contact, instead of many contracts with different measurement logics.

The metrics that matter in operation

It is latency, jitter and packet loss, not availability, that decide the real quality of your applications. A line can be formally available and still unusable if these values are too poor.

For real-time services such as voice, established reference values apply, and a solid SLA must be measurable against them.

MetricReference (good)Critical fromEffect when exceeded
Latency (one-way)under 50 ms, max. 150 msover 150 msDelayed, unnatural conversations
Jitterunder 30 msover 30 msDropouts, choppy speech
Packet lossunder 1 %1 to 2 %Voice and video services unusable
Established reference values for real-time services, based on ITU-T G.114 among others.

ITU-T Recommendation G.114 specifies a maximum one-way latency of 150 ms, while for most enterprise applications under 50 ms is considered excellent. A good WAN-SLA guarantees these values as a commitment with clear priority classes, not as a non-binding target range. Check whether the figures are given as a monthly average or as a percentile, because a monthly average can hide short but business-critical spikes.

MTTR: the underrated key figure

The MTTR, the mean time to repair, is often more important in daily operation than the advertised availability. It determines how long a site is actually offline during an incident, and that is exactly what the business feels.

Watch three points. First, is the MTTR guaranteed or only a target value? Second, when does the clock start, at ticket creation or at fault confirmation? Third, are response time and restoration time shown separately? A fast response is of little use if the actual restoration remains open.

For redundantly connected sites, the focus shifts from the single outage to the question of how quickly and automatically the failover kicks in. SAVECALL defines these points together with you and fixes them consistently across all carriers.

Check penalties and the fine print

Without a penalty, any SLA promise stays consequence-free. Service credits are the only part of the contract with real financial effect when the provider misses its values.

What matters is the amount, the trigger threshold and the procedure. Are credits granted automatically or only on request within a deadline? In most cases they cover only a fraction of the actual business loss anyway. Their real value lies in forcing the provider to deliver reliable quality.

In the fine print, it pays to look at the exceptions: force majeure, third-party shares on the last mile and the treatment of the access line. Especially when several carriers are involved, accountability gaps arise here that become expensive during an incident.




How SAVECALL supports you

SAVECALL evaluates WAN-SLAs vendor-neutrally across more than 80 carriers and makes them comparable. We check not just the advertised availability, but the measurement method, guaranteed values for latency and packet loss, the MPLS– and SD-WAN-specific SLA models, and the penalties. For your entire site connectivity we bundle the individual SLAs into ONE unified SLA with ONE point of contact. This closes accountability gaps between providers, so during an incident you know exactly who delivers within which time.

Conclusion: the SLA is the actual service

The SLA is not the fine print attached to the line, it is the actual service you are buying. Anyone who only looks at the advertised availability is comparing figures that are not comparable. What matters is the measurement method, guaranteed metrics, a guaranteed MTTR and effective penalties. SAVECALL checks these points vendor-neutrally and aligns the SLA with your actual needs per site, instead of one carrier’s standard contract.

Frank Frommknecht, Key Account Consultant at SAVECALL

Written by

Frank Frommknecht

Key Account Consultant, SAVECALL

Has supported companies for over 20 years in selecting and optimizing their connectivity solutions. His focus: making complex telecommunications understandable from the customer’s perspective and finding the right solution strategically.

Sources

  • ITU-T, Recommendation G.114 (One-way transmission time), International Telecommunication Union
  • ITU-T, Recommendation Y.1541 (Network performance objectives for IP-based services)
  • SAVECALL, WAN and site connectivity

Frequently asked questions

Frequently asked questions about WAN-SLA and MTTR

What is a WAN-SLA?

A WAN-SLA (Service Level Agreement) is a provider’s contractual commitment to the quality of your site connectivity. It defines measurable values for availability, latency, jitter, packet loss and mean time to repair (MTTR), plus the consequences if these values are missed. A solid SLA does not just state an availability percentage, it fixes measurement points, measurement method and service credits. These details decide whether the promise really holds up when an outage occurs.

What does MTTR mean in a WAN contract?

MTTR stands for Mean Time To Repair, the average time from ticket to service restoration. It is often more important than the advertised availability, because it determines how long a site is actually offline during an incident. Check whether the MTTR is guaranteed or only a target value, when the clock starts and whether response time and restoration time are shown separately. Only a guaranteed MTTR backed by a penalty is truly reliable.

Which values for jitter, latency and packet loss are acceptable?

For real-time services such as voice, established reference values apply. ITU-T Recommendation G.114 specifies a maximum one-way latency of 150 ms, jitter should stay below 30 ms and packet loss below 1 percent. From around 1 to 2 percent packet loss, voice and video services become unusable. For most enterprise applications, latency below 50 ms is considered excellent. A good WAN-SLA guarantees these values as a commitment, not just as a non-binding target range.

Is 99.9 percent availability enough?

That depends on the site. 99.9 percent availability allows roughly 8.8 hours of downtime per year, 99.99 percent only about 52 minutes. For business-critical sites with real-time or production applications, the jump to 99.99 percent is often decisive. More important than the raw percentage is how availability is measured, whether planned maintenance windows are excluded and how quickly incidents are resolved. SAVECALL checks these details across providers.

What are service credits and how important are they?

Service credits are refunds or penalties the provider pays when it misses the SLA. They are the only part of the SLA with real financial effect, because without a penalty a commitment stays consequence-free. Check the amount, the trigger threshold and whether credits are granted automatically or only on request. Credits usually cover only a fraction of the actual business loss, so they work more as a lever for provider quality than as genuine compensation.

How does SAVECALL help evaluate WAN-SLAs?

SAVECALL compares SLAs vendor-neutrally across more than 80 carriers and makes them comparable. We check not just the advertised percentages, but measurement method, MTTR definition, penalties and the exceptions in the fine print. For your entire site connectivity we bundle the individual SLAs into ONE unified SLA with ONE point of contact. This closes accountability gaps between multiple providers, so during an incident you know exactly who delivers within which time.

Articles that may also interest you

Kunden

ZVEI e.V. – German Electro and Digital Industry Association, customer of SAVECALL Telecommunications Consulting
TotalEnergies, customer of SAVECALL Telecommunications Consulting
TELUS, customer of SAVECALL Telecommunications Consulting
Synopsis SAVECALL partner
Social Chain, customer of SAVECALL Telecommunications Consulting
smava, customer of SAVECALL Telecommunications Consulting
Sivantos, customer of SAVECALL Telecommunications Consulting
Sanacorp, customer of SAVECALL Telecommunications Consulting
Nippon Seiki, customer of SAVECALL Telecommunications Consulting
MWB, customer of SAVECALL Telecommunications Consulting
MSC, customer of SAVECALL Telecommunications Consulting
Kraftanlagen München, customer of SAVECALL Telecommunications Consulting
McDermott, customer of SAVECALL Telecommunications Consulting
Magna, customer of SAVECALL Telecommunications Consulting
LV 1871, customer of SAVECALL Telecommunications Consulting
Lebenswege, customer of SAVECALL Telecommunications Consulting
Korian, customer of SAVECALL Telecommunications Consulting
Kekst CNC, customer of SAVECALL Telecommunications Consulting
Käuferportal, customer of SAVECALL Telecommunications Consulting
item, customer of SAVECALL Telecommunications Consulting
Ingram, customer of SAVECALL Telecommunications Consulting
ILF Consulting Engineers, customer of SAVECALL Telecommunications Consulting
Hyatt, customer of SAVECALL Telecommunications Consulting
Heinrich-Böll-Stiftung, customer of SAVECALL Telecommunications Consulting
Fressnapf, customer of SAVECALL Telecommunications Consulting
SAVECALL partner financial.com
Financial.com, customer of SAVECALL Telecommunications Consulting
Contora, customer of SAVECALL Telecommunications Consulting
Cognizant, customer of SAVECALL Telecommunications Consulting
Bitmarck, customer of SAVECALL Telecommunications Consulting
AVIA, customer of SAVECALL Telecommunications Consulting
Aurelius, customer of SAVECALL Telecommunications Consulting
Almeda, customer of SAVECALL Telecommunications Consulting
Allianz Handwerker Services, customer of SAVECALL Telecommunications Consulting
Allianz Global Assistance, customer of SAVECALL Telecommunications Consulting
Allianz, customer of SAVECALL Telecommunications Consulting
Advantest, customer of SAVECALL Telecommunications Consulting

Why

Auswahl & Betrieb weltweiter Connectivity- & Cloud-Infrastruktur. Ohne Vendor-Risiko & unnötige Kosten.

Was Sie weiterbringt – &

bewegt

Kostenlose Expertenberatung buchen