Photo by Nellie Adamyan on Unsplash
A customer emails asking about your uptime guarantee. You type "99.9%" because it sounds good, hit send, and move on. Six months later your service goes down for four hours during a deploy gone wrong, and that same customer is now asking why you're in breach of a commitment you never actually calculated.
This happens constantly with small teams and solo founders. SLA numbers get picked based on what looks impressive rather than what's achievable, and nobody does the math until it's too late. This guide is the math, the terminology, and the practical framework for setting SLA commitments you can actually keep. If you're searching for uptime SLA explained (nines table) content because you need real numbers, not marketing copy, you're in the right place.
What is an Uptime SLA?
A Service Level Agreement is a contract, formal or informal, that defines the reliability standard you're promising your customers. At its core, an uptime SLA states a percentage of time your service will be available and operational within a given period, along with what happens if you miss that target.
SLAs exist because "we'll try our best to stay online" isn't something customers can plan around. A business running its checkout flow through your API needs to know if you're realistically available 99% of the time or 99.99% of the time, because those two numbers imply wildly different amounts of acceptable disruption. The SLA turns an implicit expectation into an explicit, measurable commitment.
For small teams, SLAs matter more than founders often assume. Enterprise customers frequently won't sign a contract without one. Even non-enterprise customers use your stated uptime as a proxy for how seriously you take reliability. A vague "we aim for high availability" reads as amateur. A specific "99.9% monthly uptime, tracked publicly, with credits for breaches" reads as a team that understands its own infrastructure.
The relationship between SLAs and trust runs in both directions. A well-calibrated SLA that you consistently meet builds credibility over time. Customers stop worrying about your reliability and start treating your service as infrastructure they can build on. But an SLA you routinely miss does the opposite: it signals that your commitments don't mean anything, which is worse than never having stated a number at all. Broken promises erode trust faster than modest, honest ones ever could.
There's also a common misconception worth clearing up early: an SLA is not a description of your best-case performance, it's a floor. If your infrastructure typically runs at 99.95% but you're not confident you can sustain that under stress, don't put 99.95% in the contract. Commit to something you can hit even during a bad quarter, then let your actual performance exceed it. The SLA number is a promise, not an aspiration.
Another misconception: people assume SLAs only cover total outages. In reality, most SLA definitions include degraded performance, elevated error rates, and slow response times above a defined threshold, not just "site is completely down." How you define downtime in your contract determines how strict your commitment actually is, and it's worth being precise about this before you publish a number anywhere.
Understanding the Nines: Uptime Percentages Decoded
The shorthand "nines" comes from how uptime percentages get written out: 99% is "two nines," 99.9% is "three nines," 99.99% is "four nines," and 99.999% is the famous "five nines" that enterprise infrastructure teams love to cite. Each additional nine represents a huge jump in reliability, not a small incremental improvement, and this is the part that trips people up.
The relationship isn't linear, it's exponential. Going from 99% to 99.9% doesn't cut your allowed downtime by 10%, it cuts it by 90%. Going from 99.9% to 99.99% cuts it by another 90%. Each nine you add makes your infrastructure, monitoring, and incident response requirements dramatically harder, because you're removing an order of magnitude of acceptable failure time, not a fixed increment.
This is why 99% looks deceptively similar to 99.9% on paper but represents a completely different operational reality. Two nines allows for roughly 3.65 days of downtime per year. Three nines allows for less than 9 hours. That's the difference between "we had a rough week" and "we had one bad afternoon." Founders who quote 99% thinking it sounds close enough to 99.9% are often shocked when they actually calculate what each number permits.
To make this concrete: if your service is a personal blog or an internal tool, 99% uptime (occasional multi-hour outages, a few times a year) is genuinely fine and nobody will notice or care. If your service is a payment API that other businesses depend on for revenue, 99% means your customers experience enough disruption to start evaluating competitors. The number that's "good enough" is entirely dependent on what's built on top of your service, not on some universal standard of quality.
The Complete Nines Table: Downtime Allowance by Percentage
This is the reference table worth bookmarking. It's the practical core of any uptime SLA explained (nines table) breakdown, because seeing the actual hours and minutes side by side is what makes the exponential jump real instead of abstract.
| Uptime % | Nines | Downtime/Year | Downtime/Month | Downtime/Week | Downtime/Day |
|---|---|---|---|---|---|
| 90% | one nine | 36.5 days | 73 hours | 16.8 hours | 2.4 hours |
| 95% | , | 18.25 days | 36.5 hours | 8.4 hours | 1.2 hours |
| 97% | , | 10.96 days | 21.9 hours | 5.04 hours | 43.2 min |
| 98% | , | 7.3 days | 14.6 hours | 3.36 hours | 28.8 min |
| 99% | two nines | 3.65 days | 7.3 hours | 1.68 hours | 14.4 min |
| 99.5% | two and a half | 1.83 days | 3.65 hours | 50.4 min | 7.2 min |
| 99.9% | three nines | 8.76 hours | 43.8 min | 10.1 min | 1.44 min |
| 99.95% | three and a half | 4.38 hours | 21.9 min | 5.04 min | 43.2 sec |
| 99.99% | four nines | 52.6 min | 4.38 min | 1.01 min | 8.64 sec |
| 99.999% | five nines | 5.26 min | 26.3 sec | 6.05 sec | 0.86 sec |
| 99.9999% | six nines | 31.5 sec | 2.63 sec | 0.6 sec | 0.09 sec |
A few things stand out once you look at this laid out. First, the drop from 99% to 99.9% takes you from over 3 days of annual downtime to under 9 hours. That's the single biggest practical jump most small teams will ever consider making, and it typically requires real investment in redundancy, not just "being more careful."
Second, once you're past four nines, your monthly downtime budget is measured in seconds. At that point you're no longer talking about "how fast can we respond to an incident," you're talking about automated failover happening before a human is even paged. Five nines and six nines are the domain of cloud providers, telecom infrastructure, and payment rails, not typical SaaS products. If you're a two-person team promising five nines, you're promising something you almost certainly cannot operationally deliver, and it's worth being honest about that early.
Industry benchmarks give useful context here. Major cloud providers like AWS, Google Cloud, and Azure typically publish SLAs in the 99.9% to 99.99% range depending on the specific service tier, with higher guarantees usually reserved for premium or multi-region configurations. SaaS products aimed at businesses commonly land at 99.9%, which has become something of a default expectation for professional B2B tools. Consumer apps and free-tier products often don't publish a formal SLA at all, or quietly operate closer to 99% to 99.5% without advertising it.
Reading the table correctly means matching the row to your actual incident history, not to what sounds impressive. If you pull your last twelve months of monitoring data and calculate your real uptime, you'll get an actual number in this table's ballpark. That number, or a slightly more conservative version of it, is your honest starting point for an SLA commitment. Pulling a number from a competitor's marketing page and copying it is how teams end up promising reliability they've never actually measured themselves capable of.
Choosing the Right SLA Level for Your Small Team
Picking an SLA tier starts with an honest assessment of what your service actually does and how much pain an outage causes your customers. A tool that generates weekly PDF reports can tolerate more downtime than a tool that processes live payments or serves as critical infrastructure inside someone else's product. Before you pick a number, map out what breaks downstream when you're unavailable, and for how long that's tolerable.
The common tiers small teams gravitate toward, and what they signal:
99% uptime is appropriate for internal tools, early-stage products still finding product-market fit, or services where customers have workarounds during downtime. It's honest, it's easy to hit without heroic infrastructure investment, and it doesn't overpromise. The downside is that it can read as unambitious to enterprise buyers who expect more from anything they're paying for.
99.5% uptime sits in a middle zone that's rarely marketed but often what teams actually deliver in practice. It's a reasonable target if you have basic monitoring and a responsive on-call process but haven't invested in redundant infrastructure yet.
99.9% uptime is the de facto standard for professional SaaS products. It signals "we take this seriously" without requiring the multi-region, multi-provider redundancy that higher tiers demand. Most small teams with solid monitoring, alerting, and a reasonably fast incident response process can sustain this if they're not also shipping risky changes directly to production without safeguards.
99.95% uptime requires meaningfully better infrastructure discipline: staged rollouts, health checks before traffic shifts, and usually some form of redundancy at the application or database layer. This is achievable for small teams but requires deliberate architecture decisions, not just good intentions.
99.99% uptime generally requires infrastructure that most small teams don't have and often don't need: multi-region failover, automated traffic rerouting, and mature incident response with on-call rotations that can respond within minutes at any hour. Promising this without that infrastructure is a recipe for public SLA breaches.
The cost and complexity trade-offs scale steeply with each tier above 99.9%. Redundancy costs money in infrastructure spend and engineering time. On-call rotations cost money in team burnout if not staffed properly. Automated failover systems cost money in engineering complexity and ongoing maintenance. Every nine you add above three nines is a multiplier on operational cost, not a fixed increase, which is exactly why so few companies actually operate at five nines despite it being the number everyone likes to cite.
The single biggest mistake small teams make is over-committing beyond what their infrastructure supports because a competitor's pricing page says 99.99% and it feels necessary to match it. Nobody is checking your infrastructure diagram before signing a contract. They're trusting the number. If you can't sustain it, you're setting yourself up for credits, refunds, and reputation damage that costs far more than just being honest about 99.9% from the start.
Building credibility happens by consistently meeting a realistic target, not by publishing an aspirational one. A team that promises 99.9% and delivers 99.95% looks excellent. A team that promises 99.99% and delivers 99.9% looks like it's failing, even though the actual performance is identical in both scenarios. The number you publish is the bar people measure you against, so set it where you can comfortably clear it.
Building Systems to Meet Your SLA Commitments
Once you've picked a target, the real work is building the systems that let you hit it consistently, quarter after quarter, not just during a good month.
Infrastructure redundancy and failover is the foundation. This means no single point of failure sitting between your customer and your service: redundant database replicas, multiple availability zones if you're on a cloud provider, and load balancers that can route around a failed instance without manual intervention. You don't need multi-region redundancy to hit 99.9%, but you do need to eliminate the obvious single points of failure that would take down your entire service from one bad server.
Monitoring and alerting is what tells you when you're at risk of breaching your SLA before your customers tell you first. This means checking uptime from multiple locations, monitoring both the surface-level "is it up" signal and deeper health checks like database connection latency or queue depth. It also means alerting thresholds tuned so you're notified fast enough to respond within your SLA's downtime budget. If your monthly budget is 43 minutes at 99.9%, you need to know about an outage in the first few minutes, not after a customer complaint. Setting this up properly is covered in detail in our guide on webhook alerting for small teams, which walks through getting real-time notifications routed to the right person immediately.
Incident response procedures determine how fast you go from "something's wrong" to "resolved." This means having a documented process, not figuring it out live while customers are affected. Know who gets paged, what the escalation path looks like if the first responder doesn't answer, and what the first three diagnostic steps are for your most common failure modes.
On-call scheduling and runbooks matter more than most small teams expect. A three-person team can still run a lightweight on-call rotation, even if it's just "whoever's on call that week gets the page." The runbook doesn't need to be exhaustive, but it should cover your top five most likely failure scenarios with step-by-step recovery instructions, so resolution doesn't depend on one person's memory being available at 3am.
Status page communication during outages is both an SLA compliance tool and a trust-building one. Publicly acknowledging an incident as it happens, rather than staying silent and hoping nobody notices, reduces support ticket volume and shows customers you're actively managing the situation. Our guide on status page best practices covers how to structure this so it builds confidence instead of amplifying panic.
Measuring actual uptime versus promised uptime closes the loop. You need a source of truth for uptime calculation that's independent of your own infrastructure, ideally third-party monitoring that checks your service the way a real customer would experience it. This is also where the distinction between synthetic checks and real user monitoring becomes relevant. Our comparison of synthetic vs real user monitoring breaks down which approach gives you more accurate SLA compliance data for a small team's setup.
Communicating SLAs to Customers and Stakeholders
The way you present your SLA matters almost as much as the number itself. Vague language creates disputes later, so specificity protects both you and your customer.
In contracts and documentation, define exactly what counts as downtime, over what measurement window (calendar month is standard), and how uptime percentage gets calculated. Specify what's excluded, typically scheduled maintenance announced with advance notice, and be explicit about that notice period. A contract that says "99.9% uptime, excluding planned maintenance" without defining planned maintenance leaves room for abuse on either side.
Setting expectations around maintenance windows means telling customers in advance, through email or your status page, when you're taking the service down intentionally, and keeping those windows as short and infrequent as possible. Frequent "planned maintenance" starts to look like a loophole for hiding real reliability problems, and sophisticated customers will notice the pattern.
Transparency in status pages and incident reports builds long-term trust in a way that hiding problems never does. A public incident history, with honest postmortems explaining what went wrong and what's changing to prevent recurrence, turns outages into credibility-building moments instead of pure liabilities. Our incident communication templates guide has ready-to-use language for these situations so you're not drafting customer-facing messages from scratch while you're also fighting the actual fire.
SLA credits and compensation policies should be specific and automatic where possible. A common structure is tiered credits based on how far below the SLA target actual uptime fell, issued as account credit rather than cash refunds. Whatever policy you choose, publish it clearly rather than handling breaches case by case, which creates inconsistency and resentment among customers who compare notes.
Building trust through consistent delivery is ultimately the whole point of this exercise. An SLA is a promise you make repeatedly, month after month, and the compounding effect of keeping it is what turns a customer into a long-term account rather than a one-time signup.
FAQ
What counts as downtime in SLA calculations?
Downtime typically means any period where your service is unavailable or performing below an agreed threshold, such as error rates above a set percentage or response times exceeding a defined limit. Total outages obviously count, but degraded performance often counts too if your contract defines it that way. Most SLAs exclude scheduled maintenance that's announced with proper advance notice, and many exclude downtime caused by factors outside your control, like a cloud provider's regional outage, though this depends on your specific contract language.
How do I calculate my actual uptime percentage?
The standard formula is: (total time in period minus downtime) divided by total time in period, multiplied by 100. For a 30-day month, that's 43,200 total minutes. If you had 30 minutes of qualifying downtime, your uptime is (43,200 - 30) / 43,200 = 99.93%. The accuracy of this number depends entirely on how reliably you're detecting and logging downtime, which is why independent monitoring matters more than self-reported logs.
Can I improve my SLA without major infrastructure investment?
Yes, to a point. Faster incident detection and response often closes more of the gap than infrastructure spend does, especially if you're currently taking 30+ minutes to notice an outage. Better monitoring coverage, clearer runbooks, and a functioning on-call rotation can move you from 99% to 99.9% territory without touching your architecture. Beyond 99.9%, you generally do need redundancy investment, because human response time alone can't compensate for a single point of failure going down.
What's the difference between SLA and SLO?
An SLO (Service Level Objective) is an internal target your team uses to guide engineering priorities, often set more aggressively than your public SLA. An SLA is the external, contractual commitment with consequences attached if you miss it. A common practice is setting your SLO slightly higher than your SLA, so you have a buffer before an internal target miss becomes a customer-facing contract breach.
Should small startups commit to high nines?
Generally no, not early on. Committing to 99.99% or higher before you have the infrastructure and team capacity to sustain it creates risk without corresponding benefit, since most early customers care more about responsiveness and product fit than a marginal difference between 99.9% and 99.99%. Start with a number you can consistently beat, build a track record, and raise your published commitment as your infrastructure and processes mature. Reliability reputation is built over time, not claimed upfront.
Setting up the monitoring to actually track your SLA compliance is the natural next step once you've picked a target. If you want to see what that looks like in practice, Uptiqr's features cover uptime checks, status pages, and alerting built specifically for small teams trying to hit realistic, well-measured SLA targets, and the pricing page shows what it costs to get started.