An SLA (Service Level Agreement) is a written agreement that defines the quality a provider commits to, the time frames and metrics it will be held to, and what happens when those commitments are not met.
Launching a website, mobile app or business application is not the finish line; the real question is how reliably that system will run every single day. "What happens if the site goes down?" and "How quickly will someone respond when I report a bug?" are questions an SLA answers. In this article we cover the core concepts behind SLAs, what uptime percentages actually mean and the clauses a good agreement should include.
What is the difference between an SLA, an SLO and an SLI?
These three acronyms are often used interchangeably, but they describe different things:
- SLI (Service Level Indicator): The metric you measure. For example, the share of successful requests, page response time or the share of minutes in which the system was available.
- SLO (Service Level Objective): The internal target you set for that metric, such as "99.9% of requests succeed" or "95% of pages respond in under 500 milliseconds".
- SLA (Service Level Agreement): The contractual version of those targets, promised to the customer and backed by consequences. Missing the target triggers service credits, fee reductions or termination rights.
In a healthy setup, the internal objective (SLO) is stricter than the value committed in the contract (SLA). That gap gives the team room to spot and fix problems before the promise to the customer is broken.
How much downtime does 99.9% uptime really allow?
Uptime percentages look almost identical on paper, but the small differences translate into very different amounts of downtime:
- 99%: About 3.65 days a year, or roughly 7 hours 18 minutes a month.
- 99.5%: About 1.8 days a year, or roughly 3 hours 39 minutes a month.
- 99.9%: About 8 hours 46 minutes a year, or roughly 44 minutes a month.
- 99.95%: About 4 hours 23 minutes a year, or roughly 22 minutes a month.
- 99.99%: About 53 minutes a year, or roughly 4 minutes a month.
Every extra "nine" requires noticeably more investment in infrastructure, monitoring and operations. So the right question is not "what is the highest percentage we can get?" but "what does one hour of downtime cost our business?" For a corporate website, 99.5% is often enough, while an e-commerce platform that takes payments or a panel that runs daily operations usually aims for 99.9% or higher.
Why should response time and resolution time be defined separately?
The most common misunderstanding in SLAs is confusing response time with resolution time. Response time is how long it takes for a specialist to first get back to you after you report an issue. Resolution time is how long it takes to fix the problem, or at least to put a workaround in place that keeps the business running.
To make these times meaningful, requests are grouped into priority levels. A sample structure might look like this:
- Critical (P1): The system is completely unavailable or a core function such as payments has stopped. Response within 30 minutes, workaround within 4 hours.
- High (P2): An important function is broken but the system still runs. Response within 2 hours, resolution within 1 business day.
- Medium (P3): A bug that affects users but has a workaround. Response within 1 business day, resolution in the next planned release.
- Low (P4): Visual glitches, copy fixes and small improvement requests. Response within 2 business days, resolution according to the roadmap.
These times are only examples and should be set according to how critical each project is. What matters is that every level is clearly defined and that the agreement states in advance who decides which level a request belongs to. It should also be clear whether the clock runs 24/7 or only during business hours; the difference between a critical request opened on a Saturday night and one opened on Monday morning depends entirely on this detail.
Which clauses belong in a good SLA?
Instead of a one-page list of promises, an agreement that covers the following topics protects both the customer and the provider:
- Scope of service: Which systems, which environments (production, staging) and which components are covered?
- Measurement method: How and from where is availability measured, and is the measurement period monthly or yearly?
- Target values: Uptime percentage, response and resolution times and, where needed, performance targets.
- Support channels and hours: Through which channel are requests opened, and who do you reach in a critical situation?
- Planned maintenance: When do maintenance windows happen, how far in advance are they announced and do they count toward availability?
- Exclusions: Force majeure, issues caused by the customer's own changes and third-party services outside the agreement.
- Remedies: What service credits apply when targets are missed, and do repeated breaches create a right to terminate?
- Reporting: Monthly availability reports, post-incident reviews (post-mortems) and regular review meetings.
A good SLA is not about what happens when things go well; it spells out who does what when things go wrong.
How do service credits work?
A service credit is a discount deducted from the next invoice when the committed level is not met. Credits are usually tiered: for example, 10% of the monthly fee if monthly availability drops below 99.9%, and 25% if it drops below 99%. Service credits rarely cover the full cost of an outage to the business; their real purpose is to give the provider a strong incentive to invest in reliability. That is why the agreement should also state how credits are claimed, for instance within how many days after the end of the month.
How do dependencies affect an SLA?
A modern web system is never a single piece: cloud servers, databases, email services, payment gateways, maps or authentication providers. Each dependency has its own SLA, and the reliability of the whole chain can be lower than its weakest link. A system that needs two independent services, each offering 99.9% availability, has a theoretical availability of about 99.8%.
This means a software team cannot promise its customer more than the services it relies on promise to it. Redundancy, automatic retries, queues and caching for critical dependencies help close that gap. On the backup side, two concepts matter: RTO (Recovery Time Objective, the maximum time it takes to bring the system back after an outage) and RPO (Recovery Point Objective, the maximum amount of data loss that is acceptable). Both values should be written into the SLA.
How is an SLA measured and tracked?
An SLA that is not measured is only a statement of good intentions. These steps make tracking reliable:
- Set up external monitoring. Use an independent monitoring tool that checks availability every minute from several locations.
- Measure the real user experience. Do not only check whether the site loads; test whether critical flows such as sign-in, search and checkout actually work.
- Define alerts and an on-call rota. Make it clear who gets alerted when a critical issue happens at midnight and how they respond.
- Record every incident. Capture start and end times, impact, root cause and follow-up actions in an incident report.
- Report monthly. Share availability, the requests opened and adherence to response and resolution times every month.
This discipline works best alongside a development culture where issues are spotted quickly and changes ship safely in small steps. We covered this in detail in DevOps Without the Drama. Security incidents also need their own response plan, and our cybersecurity checklist is a good place to start.
Frequently asked questions
Is an SLA the same as a maintenance contract?
No. A maintenance contract defines what work will be done (updates, backups, small improvements); an SLA defines the quality and time frames for that work and how they are measured. In most projects, the two appear as different sections of the same contract.
Can anyone promise 100% uptime?
Not realistically. Hardware, networks, cloud providers and software layers are all imperfect. A contract that promises 100% usually leaves the measurement method vague or keeps the exclusions broad. An honest, measurable target is always worth more.
Does a small corporate website need an SLA?
It may not need a detailed contract, but the basic commitments should still be in writing: an availability target, backup frequency, security updates and who to contact, and how, when something goes wrong.
Who should measure the SLA?
Ideally, both parties should have access to the same data. In addition to the provider's monitoring reports, an independent status page or monitoring tool that the customer can also see prevents disputes before they start.
Where to start?
First, list the parts of your system that directly cost you money or reputation when they fail. Then set realistic availability targets, priority levels and response times for those parts, and put the monitoring in place to measure them. Designing the SLA together with the software is always easier than bolting it on later, which is why it belongs in the first weeks of any software development project.
If you want to define the right service level for your project together, touch the future and let's talk.