What Is an SLA (Service Level Agreement)?
A Service Level Agreement (SLA) is a formal contract or contract section that specifies the measurable performance a service provider commits to, such as system uptime, response time to support requests, and resolution time for incidents. It also defines what happens if those targets are not met, often through service credits or penalties. SLAs are common in software hosting, IT support, and outsourced application maintenance, where both parties need a clear, objective reference point for what 'good service' means.
An SLA is a written agreement that defines the level of service a provider guarantees, including uptime, response times, and what happens when those commitments are missed.
Why Verbal Promises Aren’t Enough
“We will fix it quickly” and “the system will be reliable” sound reassuring, but neither statement is measurable. If a critical issue takes six hours to get a response, was that quick? If the system is down for three hours a month, is that reliable? Without a number and a timeframe attached, both sides are relying on differing assumptions, and disputes over “reasonable” service are hard to resolve because there is no agreed baseline to point to.
An SLA fixes this by converting vague expectations into specific, measurable commitments: a percentage, a number of minutes, a response-time tier. Once both sides have agreed to a number, “was the target met” becomes a factual question rather than an opinion.
The Core Elements of an SLA
A working SLA typically covers three things. First, uptime or availability: the percentage of time the system is expected to be operational, usually measured monthly, expressed as something like 99.9%. Second, response time: how quickly the provider acknowledges an issue after it is reported, often tiered by severity, with critical issues acknowledged faster than minor ones. Third, resolution time: how long the provider has to actually fix the issue once it is acknowledged, again usually tiered by severity.
A well-written SLA also defines how these metrics are measured (which monitoring tool, which time zone, which hours count) and what remedies apply if targets are missed, most commonly service credits proportional to the size of the shortfall.
Severity Tiers in Practice
Not every issue deserves the same urgency, so SLAs typically define severity levels. A critical issue, such as the entire system being down for all users, might carry a one-hour acknowledgement target and a four-hour resolution target. A minor cosmetic bug affecting no core functionality might carry a target measured in business days rather than hours. Defining these tiers clearly upfront avoids disputes later about whether a given issue “should have” been treated as urgent.
SLAs and Ongoing Change Management
SLAs are not just about outages; they also interact with how a system evolves over time. A poorly reviewed change to a production system, pushed without proper testing, is one of the most common causes of SLA breaches. This is why mature service arrangements pair an SLA with a clear change management process: changes to a live system are logged, assessed for risk, and scheduled deliberately, precisely because an uncontrolled change can turn into unplanned downtime that violates the very uptime guarantee the SLA promises.
Negotiating an SLA That Actually Protects You
When reviewing a proposed SLA, look past the headline uptime number. Check what counts as downtime (does a slow but technically “up” system count?), which hours are covered, how remedies are calculated, and whether the remedy is proportional to the actual business impact of an outage. A 99.9% uptime guarantee with a two-day acknowledgement time for critical issues is a weaker agreement than it looks, since a fast enough fix depends on both numbers working together, not just the uptime percentage in isolation.
Our tip: Before signing any SLA, ask for the exact monitoring method used to measure uptime and how a missed target actually gets reported to you. An SLA you have to actively investigate to enforce is far less valuable than one where breaches are automatically flagged and communicated.
Frequently asked questions
What is a typical uptime guarantee in an SLA?
Common tiers are 99.5%, 99.9%, and 99.99% uptime, often called 'three nines,' 'four nines,' and so on. The difference sounds small but is significant in practice: 99.9% allows roughly 8.7 hours of downtime per year, while 99.99% allows only about 52 minutes. Higher guarantees generally cost more, since they require more redundant infrastructure and faster incident response. It is worth checking which hours count: some SLAs only measure uptime during business hours, not around the clock.
What happens if a provider misses their SLA target?
Most SLAs specify remedies, most commonly service credits: a percentage discount on the next invoice, scaled to how badly the target was missed. Some SLAs include stronger penalties for severe or repeated breaches, and a small number allow contract termination without penalty if service consistently falls below agreed thresholds. It is important to read the remedy clause carefully, since a small service credit is a weak incentive if an outage caused significant business disruption.
What is the difference between an SLA and a support contract?
A support contract describes what support is provided, such as email or phone access, business hours, and included maintenance. An SLA is more specific: it attaches measurable targets and consequences to that support, such as 'critical issues acknowledged within one hour' or '99.9% uptime measured monthly.' A support contract can exist without a formal SLA, but any SLA worth having needs measurable, unambiguous metrics rather than vague commitments like 'prompt support.'
Do small businesses need an SLA with their software vendor?
Yes, especially for anything business-critical: a customer-facing website, an internal application people depend on daily, or hosted infrastructure. Without an SLA, 'we'll get to it' has no enforceable meaning; response and resolution times are whatever the vendor decides on the day. Even a simple SLA with clear response-time tiers for critical, high, and low priority issues gives a small business a concrete basis to hold a vendor accountable.