Business · 8 min read
What a credible 99.9% SLA looks like (and why “100% uptime” is a red flag)
A credible SLA promises 99.9% monthly availability, measured from outside, with clear exclusions, committed response times per priority and service credits when the target is missed. That allows about 43 minutes of downtime a month. A vendor promising 100% uptime or fixed bug-fix times is either not measuring or not telling you the truth.
By BacklooPublished
Key takeaways
- 99.9% monthly availability allows roughly 43 minutes of downtime per 30-day month, or about 8.8 hours per year.
- The SLA is the contract; the SLO is the internal target; the SLI is the measurement. A good vendor can show you all three.
- Vendors can honestly commit to response times. Resolution times depend on the problem and are best-effort.
- Look for service credits, named exclusions and inherited third-party SLAs. “100% uptime” claims are a warning sign.
What makes an SLA credible
A credible SLA is specific enough to be measured and honest about what can go wrong. It defines availability precisely, sets a realistic target such as 99.9% per month, lists what is excluded, commits to response times by priority, and says what you get back when the target is missed. Anything vaguer is a marketing page, not a service level.
The opposite is easy to spot: “100% uptime”, “24/7 support” with no response times, “bugs fixed within 4 hours”, and no mention of credits. These read well in a sales deck and protect nobody once something breaks.
SLA vs SLO vs SLI
An SLI (service level indicator) is the measurement, an SLO (service level objective) is the internal target for that measurement, and an SLA (service level agreement) is the contractual promise with consequences. The SLO is usually stricter than the SLA, so the team reacts before the contract is at risk.
| Term | What it is | Example | Who cares |
|---|---|---|---|
| SLI | A measured ratio of good events to all events | Share of HTTP requests that returned a non-5xx response within 1 s | Engineers |
| SLO | Internal target for an SLI over a window | 99.95% of requests good over a rolling 30 days | Engineering + product |
| SLA | Contractual commitment with remedies | 99.9% monthly availability, service credits below target | Client + vendor |
Ask a vendor for the SLI definition behind their SLA. If availability is “the server responded to a ping”, the number can stay green while your users see errors.
The downtime math: what each number allows
Each extra nine cuts the allowed downtime by a factor of ten. At 99.9% you get about 43 minutes per 30-day month; at 99.99% you get about 4 minutes, which is less time than most teams need to notice, diagnose and roll back a bad deploy by hand.
| Availability | Per month (30 days) | Per year (365 days) | Realistic for |
|---|---|---|---|
| 99% | 7.2 hours | 87.6 hours (≈ 3.65 days) | Internal tools, prototypes |
| 99.5% | 3.6 hours | 43.8 hours | Non-critical business apps |
| 99.9% | 43.2 minutes | 8.76 hours | Most production web apps and APIs |
| 99.95% | 21.6 minutes | 4.38 hours | Revenue-critical systems with redundancy |
| 99.99% | 4.32 minutes | 52.6 minutes | Multi-region systems with automated failover |
Moving from 99.9% to 99.99% is not a configuration change. It usually means redundant infrastructure across zones or regions, automated failover, zero-downtime migrations and an on-call rotation. Price it accordingly, and ask whether the business actually loses money in those extra 39 minutes.
Error budgets turn the target into a decision rule
An error budget is the amount of unreliability your SLO allows, and it tells the team when to ship and when to stop and fix. With a 99.9% SLO and one million requests a month, the budget is 1,000 failed requests. While budget remains, ship features. When it runs out, reliability work takes priority until it recovers.
# Example SLO definition (OpenSLO-style)
apiVersion: openslo/v1
kind: SLO
metadata:
name: api-availability
spec:
service: web-api
description: Requests served without a 5xx error
budgetingMethod: Occurrences
timeWindow:
- duration: 30d
isRolling: true
indicator:
spec:
ratioMetric:
good:
metricSource:
spec:
query: sum(rate(http_requests_total{code!~"5.."}[5m]))
total:
metricSource:
spec:
query: sum(rate(http_requests_total[5m]))
objectives:
- displayName: Internal target (stricter than the 99.9% SLA)
target: 0.9995The format matters less than the habit. Write the SLI down, alert on budget burn rate rather than on single errors, and review the budget in the same meeting where you plan features.
Response time vs resolution time
Response time is how quickly a qualified engineer acknowledges the issue and starts working on it. Resolution time is how long it takes to fix it. A vendor can control the first. The second depends on the bug, the data and sometimes on third parties, so honest SLAs commit to response and treat resolution as best effort with regular updates.
A promise like “all critical bugs fixed in 4 hours” either will not be kept or will be met with a rushed patch that causes the next incident. What you want instead is a commitment to respond fast, restore service first (rollback, failover, feature flag) and fix the root cause properly afterwards.
A priority matrix from P1 to P4
A priority matrix maps business impact to response commitments, so nobody argues about urgency at 2 a.m. Define the levels by what users experience, not by how annoyed the reporter is. The response times below are an illustrative example; the right values depend on your plan and business hours.
| Priority | Meaning | Example | Example response | Update cadence |
|---|---|---|---|---|
| P1 Critical | Service down or data at risk for most users | Checkout fails, login broken, data leak suspected | Within 1 hour, 24/7 | Every hour until restored |
| P2 High | Major feature degraded, no workaround | Payments slow, admin panel unusable | Within 4 business hours | Daily |
| P3 Normal | Minor feature broken, workaround exists | Export fails for one format | Within 1 business day | On progress |
| P4 Low | Cosmetic issue or question | Typo, layout glitch, how-to | Within 3 business days | On resolution |
Service credits: what happens when the target is missed
Service credits are a partial refund of the monthly fee when availability falls below the SLA. They will never cover your lost revenue, and they are not meant to. They exist so the vendor has a financial reason to hit the target and a documented consequence when it does not.
| Monthly availability | Credit |
|---|---|
| Below 99.9% | 10% of the monthly fee |
| Below 99.0% | 25% of the monthly fee |
| Below 95.0% | 50% of the monthly fee |
Check how credits are claimed. If you must file a request within a short window with your own evidence, the vendor should at least publish the measurement data you need to do it.
Exclusions every honest SLA has
Every honest SLA excludes downtime the vendor cannot control or has announced in advance. The point is not to dodge responsibility but to make the remaining promise measurable. What matters is that exclusions are named and narrow.
- Announced maintenance. Planned work announced in advance (for example 48 hours ahead), ideally in low-traffic hours and capped per month.
- Third-party providers. If the app runs on a cloud, database or payment provider, uptime on that layer inherits the provider's own SLA. A vendor cannot promise more than the platform underneath.
- Client-caused issues. Changes made outside the agreed process, exceeded usage limits, or credentials shared and compromised on the client side.
- Force majeure and attacks beyond reasonable mitigation. Defined in the contract, not used as a blanket excuse.
Why “100% uptime” is a red flag
No system that gets deployed, patched and depends on networks achieves 100% availability, so a vendor promising it is either not measuring, defining downtime away, or counting on you never checking. Experienced CTOs read it as a sign the vendor has not operated production systems seriously.
What to ask a vendor before you sign
Ask questions that force the SLA to become concrete: how availability is measured, what is excluded, what each priority means, and what you receive when they miss. A good vendor answers each in one or two sentences and can point to the clause.
- What is the exact SLI behind “availability”, and is it measured from outside your infrastructure?
- Is the target monthly or yearly, and over which calendar or rolling window?
- Which components are covered, and which inherit a third-party provider's SLA?
- How much notice do you give for maintenance, and is there a monthly cap?
- What are the response times per priority, and in which hours do they apply?
- Who decides the priority of an incident, and how can I escalate?
- What service credits apply, and how are they claimed?
- Do I get a status page, incident reports and a monthly availability report?
- Who owns the code, cloud accounts and monitoring if we part ways?
- What is included in maintenance: dependency updates, security patches, backups and restore tests?
Uptime is only half of maintenance
An SLA covers availability and response; it does not keep the codebase healthy. Dependencies age, security patches pile up and shortcuts accumulate. A maintenance plan should budget time for that work, or the SLA gets harder to meet every month.
10–20%
Planned, regular debt work is cheaper than the emergency version. We describe one way to do it in how to pay down technical debt without stopping feature work.
How Backloo phrases it in our care plans
Our care plans commit to 99.9% monthly availability on systems we host and operate. That is about 43 minutes of downtime a month, excluding maintenance announced 48 hours ahead. Below the target, service credits apply on the tiered schedule above.
- Response, not fix times. We commit to response times per priority, restore service first and fix root causes properly.
- Inherited SLAs stated openly. Uptime of third-party infrastructure follows that provider's own SLA, and the contract says so.
- Two levels. Care starts at €490 per month and Care Plus at €1,490 per month; the plan page lists exactly what each includes.
- Your GitHub, your cloud, your IP. Leaving is a handover, not a hostage negotiation.
How Backloo can help
If you are comparing vendors, use the checklist above on us too. If you already run a production app and want a written SLA with real measurement behind it, see maintenance and SLA care plans. If the system itself needs redundancy before a higher target makes sense, that is backend systems work. Questions first? Get in touch.
Questions
How much downtime does 99.9% uptime allow?
About 43.2 minutes per 30-day month, or about 8.76 hours per year. 99.95% allows about 21.6 minutes per month, and 99.99% about 4.3 minutes.
What is the difference between SLA, SLO and SLI?
The SLI is the measurement (for example, the share of successful requests), the SLO is the internal target for it, and the SLA is the contractual promise with remedies such as service credits. The SLO is usually stricter than the SLA.
Why do SLAs commit to response times and not fix times?
A vendor controls how fast a qualified engineer starts working on an issue, but not how long an unknown bug takes to fix. Honest SLAs commit to response, restore service first, and treat the root-cause fix as best effort with regular updates.
Does a 99.9% SLA cover outages of my cloud provider?
Usually not beyond what the provider itself guarantees. Uptime on third-party infrastructure inherits that provider's SLA, and a good contract names those providers explicitly.
Is a higher SLA always better?
No. Each extra nine requires more redundancy, automation and on-call cover, and costs more. Choose the target based on what an hour of downtime actually costs your business.