Glossary

What is an SLA?

An SLA is a service level agreement: guaranteed uptime in percent, latency and packet-loss targets, and service credits paid when they are missed.

Last updated:

An SLA (Service Level Agreement) is a contract for a guaranteed level of service. In it the provider commits to keep measurable link parameters and sets out the compensation owed if it fails to meet them. In carrier networks an SLA mainly describes service availability expressed as a percentage (uptime), maximum latency, latency variation (jitter), allowed packet loss, and response and repair times. If those targets are missed, the customer is owed penalties, most often in the form of service credits, that is, a refund of part of the fee.

Availability expressed as a percentage

Availability is the most frequently quoted SLA parameter and is given as the percentage of time in a billing period during which the service is up. The number of nines matters here, because it translates directly into the allowed downtime. An SLA of 99.9 percent permits about 8 hours 46 minutes of outage per year, 99.99 percent leaves only about 53 minutes a year, and 99.999 percent (five nines) means roughly 5 minutes per year. The contract should clearly define how availability is calculated and what counts as an outage.

  • 99.9% (three nines): about 8 h 46 min of downtime per year.
  • 99.95%: about 4 h 23 min per year.
  • 99.99% (four nines): about 53 min per year.
  • 99.999% (five nines): about 5 min per year.
  • Exclusions: maintenance windows, force majeure and customer-side faults usually do not count toward downtime.

Latency and packet-loss targets

Beyond raw availability, an SLA defines the quality parameters of traffic across the network. Latency is usually measured as RTT in milliseconds, most often averaged over the period and scoped to a given region or path. Jitter is the variation of that latency and matters for VoIP and video. Packet loss is given as a percentage and on a well-run backbone should be close to zero. The measurement methodology builds on the RFC 2330 (IPPM) framework, and the individual delay, loss and jitter metrics are defined by RFC 7679, RFC 7680 and RFC 3393 respectively.

Service credits and time to repair

An SLA is enforced through its penalties, the service credits. When measured availability drops below the threshold, or latency or packet loss exceeds the target, the customer is owed an agreed share of the monthly fee back, usually rising with the severity of the breach. Equally important are the incident-handling parameters: time to respond and the target time to repair (MTTR or time to restore), counted from the moment a ticket is raised with the NOC. For credits to be claimable, the contract must specify how it is measured, the reporting procedure, and the window in which the customer can request compensation.

SLAs in AS202520 SkyPass services

AS202520 SkyPass delivers IP transit, BGP peering, remote IXP access and DDoS protection backed by clearly defined SLAs. We build them on multiple independent upstreams and dense peering at Polish internet exchanges (THINX, TPIX, WRIX, 1-IX), which keeps latency low for domestic traffic and packet loss low on local paths. You can verify link parameters before signing in our public looking glass, and our NOC handles tickets with a defined response time.

Frequently asked questions

How much downtime does a 99.99% SLA allow?

Four nines is about 53 minutes of outage over a year. For comparison, 99.9% allows about 8 hours 46 minutes, while 99.999% permits only about 5 minutes per year.

What are service credits?

They are the penalties for missing an SLA, paid as a refund of part of the monthly fee. The amount usually rises with the severity of the breach in availability, latency or packet loss.

Do maintenance windows count as downtime?

Usually not. Scheduled, pre-announced maintenance windows, force majeure and customer-side faults are typically excluded from the downtime calculation in an SLA.

How are latency and packet loss measured in an SLA?

Latency is usually given as RTT in milliseconds and packet loss as a percentage, averaged over the billing period. The methodology follows RFC 2330 and the metrics in RFC 7679, 7680 and 3393.

Related articles