{"id":21551,"date":"2026-07-09T13:51:18","date_gmt":"2026-07-09T11:51:18","guid":{"rendered":"https:\/\/www.savecall.de\/?p=21551"},"modified":"2026-07-09T14:59:51","modified_gmt":"2026-07-09T12:59:51","slug":"wan-sla-mttr-worauf-achten","status":"publish","type":"post","link":"https:\/\/www.savecall.de\/en\/wan-sla-mttr-worauf-achten\/","title":{"rendered":"wan-sla-mttr-what-counts"},"content":{"rendered":"\n

\n

\n

WAN-SLA and MTTR: What Really Counts in the Contract<\/h1>\n<\/div>\n\n\n\n

Trusted Advisor for IT & Telecommunications Sourcing<\/h3>\n<\/div>\n\n\n\n
\n
\n
WAN-SLA: more than a percentage<\/h2>\n<\/div>\n<\/div>\n\n\n\n
\n
\n
\n
\n
What a WAN-SLA must deliver<\/h2>\n\n\n\n
It is not the advertised availability that decides, but the measurement method, guaranteed metrics, MTTR and penalty.<\/h6>\n\n\n\n
Almost every quote for site connectivity<\/a> 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.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Auf den Punkt gebracht:<\/strong><\/p>\n\n\n\n
\n
Read availability correctly:<\/strong> 99.9 percent means around 8.8 hours of downtime per year, 99.99 percent only about 52 minutes<\/li>\n\n\n\n
Metrics over percentages:<\/strong> latency, jitter and packet loss decide the real application quality, not availability alone<\/li>\n\n\n\n
MTTR is the lever:<\/strong> the guaranteed repair time determines how long a site is really offline during an incident<\/li>\n\n\n\n
Check penalties:<\/strong> without service credits and a clear trigger, any SLA promise stays consequence-free<\/li>\n<\/ul>\n\n\n\n<\/div>\n\n\n\n
Die L\u00f6sung:<\/strong> 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.<\/p>\n\n\n\n
Worum es in diesem Beitrag geht:<\/strong> 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.<\/p>\n\n\n\n
\n
Book a consultation<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n
\n
\n
Table of contents<\/h3>\n\n\n\n
\n
What is a WAN-SLA really?<\/a><\/li>\n\n\n\n
Availability: why 99.9 is not always 99.9<\/a><\/li>\n\n\n\n
The metrics that matter in operation<\/a><\/li>\n\n\n\n
MTTR: the underrated key figure<\/a><\/li>\n\n\n\n
Check penalties and the fine print<\/a><\/li>\n\n\n\n
Conclusion<\/a><\/li>\n\n\n\n
Frequently asked questions<\/a><\/li>\n<\/ul>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n

\n
\n
\n
\n
\n
\n
\n
\n
\n<\/p>\n\n\n
\n
\n
What is a WAN-SLA really?<\/h3>\n\n\n\n
A WAN-SLA is the contractual commitment to the quality of your site connectivity<\/a>, 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Availability: why 99.9 is not always 99.9<\/h3>\n\n\n\n
Availability sounds unambiguous, but it is not. Each additional nine drastically shortens the permitted downtime, as the following table shows.<\/p>\n\n\n\n
Availability<\/th> Max. downtime per year<\/th> Max. downtime per month<\/th><\/tr><\/thead>
99.0 %<\/td> approx. 3.65 days<\/td> approx. 7.3 hours<\/td><\/tr>
99.9 %<\/td> approx. 8.8 hours<\/td> approx. 43.8 minutes<\/td><\/tr>
99.99 %<\/td> approx. 52.6 minutes<\/td> approx. 4.4 minutes<\/td><\/tr>
99.999 %<\/td> approx. 5.3 minutes<\/td> approx. 26 seconds<\/td><\/tr><\/tbody><\/table>
Calculated downtime per availability class. Values rounded.<\/figcaption><\/figure>\n\n\n\n
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?<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
The metrics that matter in operation<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
For real-time services such as voice, established reference values apply, and a solid SLA must be measurable against them.<\/p>\n\n\n\n
Metric<\/th> Reference (good)<\/th> Critical from<\/th> Effect when exceeded<\/th><\/tr><\/thead>
Latency (one-way)<\/td> under 50 ms, max. 150 ms<\/td> over 150 ms<\/td> Delayed, unnatural conversations<\/td><\/tr>
Jitter<\/td> under 30 ms<\/td> over 30 ms<\/td> Dropouts, choppy speech<\/td><\/tr>
Packet loss<\/td> under 1 %<\/td> 1 to 2 %<\/td> Voice and video services unusable<\/td><\/tr><\/tbody><\/table>
Established reference values for real-time services, based on ITU-T G.114 among others.<\/figcaption><\/figure>\n\n\n\n
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.<\/p>\n\n\n\n
MTTR: the underrated key figure<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Check penalties and the fine print<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n<\/div>\n<\/div>\n\n\n

\n<\/p>\n

\n
\n<\/p>\n\n\n
\n
\n
\n
How SAVECALL supports you<\/h3>\n\n\n\n
<\/div>\n\n\n\n
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<\/a>– and SD-WAN<\/a>-specific SLA models, and the penalties. For your entire site connectivity<\/a> 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.<\/p>\n\n\n\n
<\/div>\n\n\n\n
Conclusion: the SLA is the actual service<\/strong><\/h3>\n\n\n\n<\/div>\n\n\n\n
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.<\/p>\n\n\n\n
<\/div>\n\n\n\n
\n
Book a consultation<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n
<\/p>\n\n\n
\n
\n
\n
\n
$\"Frank$ <\/figure>\n<\/div>\n\n\n\n
\n
Written by<\/p>\n\n\n\n
Frank Frommknecht<\/h3>\n\n\n\n
Key Account Consultant, SAVECALL<\/strong><\/p>\n\n\n\n
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.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n
\n
\n
$\"SAVECALL$ <\/figure>\n\n\n\n
Kostenloser<\/span> Expertentermin<\/a><\/h3>\n\n\n\n
\n
Buchen<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n
<\/p>\n\n\n
\n
\n
Sources<\/h3>\n\n\n\n
\n
ITU-T, Recommendation G.114 (One-way transmission time), International Telecommunication Union<\/li>\n\n\n\n
ITU-T, Recommendation Y.1541 (Network performance objectives for IP-based services)<\/li>\n\n\n\n
SAVECALL, WAN and site connectivity<\/a><\/li>\n<\/ul>\n<\/div>\n<\/div>\n\n\n
<\/p>\n\n\n
\n
\n
Frequently asked questions<\/h2>\n<\/div>\n<\/div>\n\n\n
<\/p>\n\n\n
Frequently asked questions about WAN-SLA and MTTR<\/h3>\n\n\n\n
What is a WAN-SLA?<\/strong>
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.<\/p> <\/div>
What does MTTR mean in a WAN contract?<\/strong>
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.<\/p> <\/div>
Which values for jitter, latency and packet loss are acceptable?<\/strong>
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.<\/p> <\/div>
Is 99.9 percent availability enough?<\/strong>
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.<\/p> <\/div>
What are service credits and how important are they?<\/strong>
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.<\/p> <\/div>
How does SAVECALL help evaluate WAN-SLAs?<\/strong>
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.<\/p> <\/div> <\/div>\n\n\n
<\/p>\n\n\n
\n
\n
Articles that may also interest you<\/h2>\n<\/div>\n\n\n\n
\r\n
\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
Internet<\/p>\r\n <\/div>\r\n\r\n
\r\n
5 Effects of a network failure<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
Mobile radio management<\/p>\r\n <\/div>\r\n\r\n
\r\n
Hybrid working – how it works!<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
Security<\/p>\r\n <\/div>\r\n\r\n
\r\n
With SD-WAN and SASE: a digital workplace that inspires!<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
Security<\/p>\r\n <\/div>\r\n\r\n
\r\n
3 things you need to know about SASE and SD-WAN<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"WAN$ <\/div>\r\n
WAN<\/p>\r\n <\/div>\r\n\r\n
\r\n
The challenge of introducing SD-WAN<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"Das$ <\/div>\r\n
WAN<\/p>\r\n <\/div>\r\n\r\n
\r\n
IPSEC shutdown in China<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"Das$ <\/div>\r\n
WAN<\/p>\r\n <\/div>\r\n\r\n
\r\n
Is China paralyzing VPN access for companies?<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
WAN<\/p>\r\n <\/div>\r\n\r\n
\r\n
Innovation in a flexible and secure corporate network<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
WAN<\/p>\r\n <\/div>\r\n\r\n
\r\n
SD-WAN – simply explained<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
Internet<\/p>\r\n <\/div>\r\n\r\n
\r\n
Digital transformation: Network edge<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n <\/div>\r\n\r\n
\r\n
Business fiber optics Munich<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
Security<\/p>\r\n <\/div>\r\n\r\n
\r\n
Does your corporate network fulfill your business ambitions?<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
WAN<\/p>\r\n <\/div>\r\n\r\n
\r\n
A specialist’s guide to your SD-WAN journey<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"Das$ <\/div>\r\n
WAN<\/p>\r\n <\/div>\r\n\r\n
\r\n
ki network determinism variance<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n
\r\n \r\n\r\n
\r\n
\r\n $\"SAVECALL$ <\/div>\r\n
WAN<\/p>\r\n <\/div>\r\n\r\n
\r\n
Global Connectivity from a Single Source<\/h3>\r\n
\r\n
Learn moreLearn more<\/h3>\r\n <\/div>\r\n <\/div>\r\n\r\n <\/a>\r\n <\/div>\r\n <\/div>\r\n\r\n
<\/div>\r\n
<\/div>\r\n
<\/div>\r\n<\/div>\r\n\r\n