What is an SLA?
It is the difference between a vendor saying they will answer fast and a contract that says what happens the day they do not.
SLA (service-level agreement)
service-level agreement
An SLA, or service-level agreement, is a contract term that sets how fast a vendor must respond to and resolve a problem with a live system. It is usually split into severity tiers, with a stated consequence if the target is missed.
An SLA covers two separate clocks. Response time is how long before a human acknowledges the problem. Resolution time is how long before it is actually fixed. A vendor can hit the first and miss the second for weeks, so a real SLA states both.
Both targets are set per severity, not as one number for every problem. A payment page erroring for every customer is not the same emergency as one admin report rendering wrong. A single blended target hides that difference, until the wrong incident gets the slow response.
What changes once it is written down
Without an SLA, response time is whatever the vendor is willing to give that week. A quiet month gets fast answers. A busy one gets silence, and neither of you can point to a number that was promised.
A written SLA turns that into something you can plan around. You know what counts as a critical incident before one happens, who gets paged, and what recourse exists if the target slips. That certainty is worth more once a system is live and customers depend on it than it was during the build.
We work to an agreed service level on every maintenance engagement, written into the contract rather than promised on a web page. The right target depends on your system and what an outage costs you. We settle it during scoping, not in the abstract.
- Severity setPayment failure, everyone affected.
- Clock startsResponse window begins on report.
- AcknowledgeNamed engineer, not a ticket queue.
- Resolve or mitigateFix, or a workaround that holds.
- Miss the targetStated consequence applies, not an apology.
Most disputes happen at the second node. "Acknowledged" and "assigned to someone" are not the same event, and a vague SLA never says which one starts the clock.
Common questions
01What is the difference between an SLA and an SLO?
An SLA is the external promise you can be held to; an SLO is the internal target a team sets to stay ahead of it. A team might run to a 99.95% SLO while the SLA it sold only commits to 99.9%, so a normal amount of slippage never breaches the contract. See SLO for the full ladder.
02What should a software SLA actually include?
Severity tiers, a response and resolution time for each, what starts the clock, named exclusions, and a stated consequence for a miss. A document listing only an uptime percentage is a marketing claim wearing an SLA's name.
03Does every maintenance contract need an SLA?
Any system customers depend on benefits from one, because it replaces a hopeful assumption with a written target both sides can check. A low-stakes internal tool can run without one. Anything customer-facing or revenue-bearing should have response and resolution times agreed before it needs them.
04What happens if a vendor misses the SLA?
Whatever the contract says, which is the entire point of writing one down. Common remedies are a service credit, an escalation to a more senior engineer, or a right to terminate after repeated misses. An SLA with no stated consequence for a miss is a description of intent, not an agreement.
