A Service-Level Agreement (SLA) is a defined, measurable performance commitment – a specific target for metrics such as latency, jitter, packet loss, or uptime – that a provider or network guarantees to meet, together with the consequence that applies when it does not. SLAs turn subjective complaints about performance into an enforceable, checkable threshold.
Key takeaways
- An SLA is a measurable performance commitment, not a vague promise.
- Common network metrics: latency, jitter, packet loss, and uptime.
- In SD-WAN, SLA profiles score paths and can reroute traffic automatically.
- Missing an SLA can trigger credits, penalties, or automatic remediation.
- Versa continuously monitors per-path SLA compliance in real time.
On this page: Why it mattersHow it worksTypesSLA & VersaFAQ
Why is an SLA important?
Without a measurable SLA, network performance is a matter of opinion – “the app feels slow” is not actionable. An SLA replaces that ambiguity with a number: a maximum latency, a minimum uptime percentage, a packet-loss ceiling. Breaching the threshold has consequences, whether contractual (service credits, penalties, termination rights) or operational (an automated failover).
That contractual-versus-operational distinction matters most in networking. A traditional ISP SLA is checked after the fact, often monthly, and a violation results in an invoice credit. A network SLA embedded in SD-WAN policy is checked continuously and can trigger an immediate, automated response – moving traffic off a noncompliant path before a user notices.
What is an SLA?
An SLA formalizes three things: the metric being measured, the target for that metric, and what happens if the target is missed. In a traditional IT services contract, the metrics are typically uptime, ticket-response time, or mean time to repair; the consequence is usually a service credit or a right to terminate.
In networking, SLAs are narrower and often automated. A network SLA typically covers latency, jitter, and packet loss, measured continuously between two points. Instead of a person checking a monthly report, software probes the path at a configured interval and marks it compliant or SLA-violated – an input to a routing decision made continuously, not just a reporting artifact.
Types of SLAs
SLAs are commonly classified by scope. A customer-based SLA covers all services delivered to one customer under a single agreement. A service-based SLA applies the same terms to every customer of a given service – most cloud and SaaS SLAs work this way. A multi-level SLA layers corporate-wide, service-specific, and customer-specific terms in one structure, common in managed-service contracts.
Networking adds a split by measurement window. A contractual SLA is reported periodically and reconciled after the fact. An operational SLA is measured continuously against a live threshold and drives an automated decision, such as which WAN path carries a flow right now – SD-WAN’s SLA profiles work this way.
SLA & Versa
Versa Secure SD-WAN implements SLAs as SLA profiles: link-performance thresholds – latency, jitter, and packet loss – that a VOS device evaluates against each path. An SLA profile attaches to a forwarding profile; when a path fails its thresholds it is marked SLA-violated, and traffic steering moves flows to the next compliant path automatically. Recomputation timers, SLA smoothing, and violation damping control how quickly that reevaluation happens, preventing flows from flapping between marginal paths.
The mechanism extends into routing: a BGP SLA profile lets peer policies select the best next hop using live SLA metrics – least latency, least packet loss, or Versa’s link score. At scale, the SD-WAN design guide recommends limiting which paths are actively SLA-monitored so probe traffic does not consume meaningful bandwidth.
Frequently asked questions
What metrics does an SLA typically measure?
The most common are latency, jitter, and packet loss for network SLAs, and uptime, response time, and mean time to repair for service contracts. Which metrics matter depends on what’s being guaranteed – real-time link performance or overall service delivery.
What happens when an SLA is violated?
It depends on the SLA’s type. A contractual violation typically triggers a service credit, penalty, or escalation clause. An operational network SLA violation – a path exceeding its latency, jitter, or loss threshold – triggers an immediate response, like SD-WAN rerouting traffic to a compliant path.
Is an SLA the same as a KPI?
No. A key performance indicator (KPI) is the metric itself – latency, uptime, response time. An SLA is the commitment built around a KPI: a target for that metric plus the consequence if it’s missed. Every SLA relies on KPIs; not every KPI has an SLA attached.
How is a network SLA different from a traditional service SLA?
A traditional service SLA, like an ISP or SaaS contract, is measured periodically and reconciled after the fact, with a credit or penalty as the remedy. A network SLA in SD-WAN is measured continuously by software and can trigger automated rerouting within seconds of a violation.
Can an SLA change traffic behavior automatically?
Yes, in SD-WAN. When a path’s live metrics breach its SLA profile’s thresholds, the path is marked noncompliant, and the forwarding profile tied to the traffic-steering policy selects the next eligible path, moving flows off the degraded link without manual intervention.
More on SLAs
If you want to learn more, these are sources we trust.
| NIST CSRC Glossary: Service Level Agreement |
|---|
| NIST’s working definition of a service-level agreement, used across federal guidance on outsourced and interconnected IT systems. |
Related terms
If you’re reading about SLAs, these are worth looking at next.
| SD-WAN | Path | Quality of Service |
|---|---|---|
| The networking layer that uses SLA-aware traffic steering to route flows across WAN links based on real-time path performance. | The end-to-end route an SLA is measured against – SD-WAN evaluates each path’s latency, jitter, and loss independently. | Traffic prioritization that works alongside SLA-based path selection to protect latency-sensitive applications during congestion. |