How to read an internet SLA: availability, latency and what the percentage actually allows

An internet SLA is only as useful as its definitions. “99.9% uptime” and “99.99% availability” look almost identical on a proposal, but over an illustrative 30-day measurement period the first allows about 43 minutes of unavailable time and the second about 4. And neither number tells you anything until the agreement says how availability is measured, over what period, from where, and what is excluded.

A percentage without those definitions is incomplete. This article explains how to read one properly, and what to ask for before you sign.

Three things that are often blurred together

Before reading any figure, separate three kinds of statement:

• An observation: what happened on a defined scope over a stated period. It describes the past.
• A standard objective: what a service is designed and agreed to meet, with its definition and scope.
• The binding commitment: what your signed agreement says for your service, including exclusions and remedies.

A good observation does not change an objective, and neither replaces your agreement. When a proposal says “our network achieved 99.99%”, ask which of the three it is.

What an availability percentage allows

Availability is the share of a measurement period during which the service is usable, as the agreement defines “usable”. The arithmetic is simple, and worth doing every time:

Each extra “9” reduces the allowed unavailable time by a factor of ten. That is why the difference between 99.9% and 99.99% is an engineering difference, not a rounding difference.

The window changes the meaning

The same outage produces very different percentages depending on the measurement period. A single 30-minute outage:

• measured over a 30-day period, is about 99.93% for that period, which misses a 99.99% objective measured monthly;
• measured over a 365-day year with no other outage, is about 99.994%, which meets a 99.99% annual objective.

Neither is wrong. They answer different questions. Ask whether availability is measured per month, per quarter or per year. Monthly measurement is the stricter and more useful one for a business that cannot absorb a long outage in any given month.

Five definitions to find in the agreement

1. What counts as unavailable. Total loss of connectivity only, or also severe packet loss or degradation? A service that technically passes traffic but loses half of it may not count as “down” under a narrow definition.
2. Where it is measured. At the provider’s equipment on your site, at the edge of its network, or somewhere else? The measurement point decides which failures count.
3. When the clock starts. From the moment monitoring detects the fault, or from when you report it? If it starts at your report, the provider’s detection speed is outside the commitment.
4. Exclusions. Planned maintenance, faults in customer equipment or power, force majeure, and third-party networks are commonly excluded. Read the list. A long exclusion list can empty a high percentage.
5. Planned maintenance. How much notice, at what times, and does maintenance count toward availability? It should be stated, not assumed.

Latency, packet loss and jitter

Availability says whether the service is usable. Performance says how well it works while it is.

• Latency (round-trip time) is the time a packet takes to reach a destination and return (RFC 2681). A latency figure only means something with its statistic (average, median, a percentile), the path it was measured on, and the period.
• Packet loss is the share of test packets that do not return within a timeout over a stated period (RFC 7680). Even small sustained loss damages voice, video and file transfers.
• Jitter (packet delay variation) is how much delay varies between packets (RFC 3393; RFC 5481 compares the ways of expressing it). It is measured with probes designed for it; the spread of a simple ping test is not a jitter measurement.

Latency to destinations inside Bangladesh and to destinations abroad are different measurements on different paths. A local latency objective tells you nothing about the path to an overseas cloud region. Every performance commitment should therefore define its measurement scope. A provider has its most direct control within its own network; measurements to remote destinations also depend on third-party networks and on the destination itself.

Response and restoration are not the same thing

Many SLAs separate how quickly the provider acknowledges and starts working on a fault (response) from how quickly service is restored (restoration). A fast response target with no restoration target tells you when someone will pick up the phone, not when your office will be back online. Check which one the agreement defines, for which severity of incident, and whether the provider monitors the service and contacts you, or waits for your call.

Service credits are a remedy, not insurance

Where service credits apply, they are contractual remedies defined by the agreement. They should not be treated as insurance or as a measure of the business cost of an outage. The design of the connection (how many paths reach the building, and what fails when one does) usually matters more than the remedy.

A checklist for any internet SLA

• Is the figure an observation, a standard objective, or a binding commitment?
• Over what window is availability measured: month, quarter or year?
• What counts as unavailable, and where is it measured?
• When does the clock start: at detection or at your report?
• What is excluded, and how is planned maintenance treated?
• Which performance metrics are defined (latency, loss, jitter), with what statistic and to which destinations?
• Are response and restoration both defined, and for which severities?
• Does the provider monitor the service and contact you first?
• What remedies apply, and when?

If a proposal cannot answer these questions in writing, compare it on design and support rather than on its percentage. For how service commitments sit next to the connection itself, see corporate internet in Bangladesh: what a dedicated connection actually commits, and FajrFiber’s own explanation of how its service levels work.