An uptime promise is a business decision with a price tag. At 99.9%, your SaaS may be down about 43 minutes in a 30-day month. At 99.99%, about 4. Each extra nine costs more servers, more testing and someone on call at night. So promise the lowest target your customers will accept, run the product against a tighter target inside the team, and build the parts that keep you there: a second copy of the app and the database, backups you’ve restored, alerts that reach a person, a status page and a rule that pauses releases when you’re over budget. Your cloud provider’s promise covers its servers. The uptime of your product is yours.
| Uptime target | Downtime in a 30-day month | Downtime in a year |
|---|---|---|
| 99% | 7 hours 12 minutes | About 87.6 hours |
| 99.5% | 3 hours 36 minutes | About 43.8 hours |
| 99.9% | About 43 minutes | About 8.8 hours |
| 99.95% | About 22 minutes | About 4.4 hours |
| 99.99% | About 4 minutes | About 53 minutes |
Read the table from your customer’s side. A planning tool used during office hours can live with a short outage on Sunday night. A payment flow or a platform that runs live events can’t. The right target depends on what your customers lose in a lost minute, which is a question for sales and support before it’s one for engineering.
Google’s SRE book chapter on service level objectives gives the clearest definitions we know.
The chapter offers a simple test: if nothing happens when you miss it, it’s an SLO, not an SLA. It also says that insisting on meeting a target 100% of the time is unrealistic and undesirable. Start with a loose target and tighten it later, and don’t copy whatever your current numbers happen to be. Keep the internal target tighter than the one you show customers, so the team has room to react before they notice.
It’s easy to assume that hosting on a big cloud means four nines. Read the contract. The Amazon EC2 SLA promises 99.99% uptime per region for instances spread across two or more Availability Zones. A single instance gets 99.5%, which allows about 3 hours 36 minutes of downtime in a 30-day month. When AWS misses, you get a service credit worth 10%, 30% or 100% of that month’s bill for the affected service. Your customers’ losses aren’t part of it.
Google’s terms work the same way. The Compute Engine SLA, last revised in October 2026, promises 99.99% for instances in multiple zones and 99.9% for a single instance of most machine types, which is about 43 minutes a month. Credits run from 10% to 100% of that service’s bill, and you have to ask Google support for them within 60 days, with logs that show the downtime.
A second zone protects you from a zone failure, not from a problem across a whole region. According to AWS’s own summary, a DNS fault in DynamoDB disrupted its Northern Virginia region from 11:48 PM on 19 October 2025 to 2:20 PM on 20 October, Pacific time. It also hit new EC2 instance launches, Network Load Balancer and Lambda there. If your promise has to survive a day like that, you need a second region, and that costs more again.
Databases need the same care. In an Amazon RDS Multi-AZ deployment with one standby, the standby takes over if the main database fails, but it doesn’t serve read traffic. A cluster with two standbys can serve reads too. Pick the setup on purpose, and know what each one costs before a customer asks.
| Part | What it does | When to add it |
|---|---|---|
| App servers in two zones | One zone can fail without taking the product down | Before your first customer who depends on it daily |
| Database with a standby | The standby takes over when the main database fails | Same time as the app servers |
| Backups you have restored | Proves the data can come back, and how long that takes | From day one, with a restore test before launch |
| Health checks and alerts | Wakes a person when users start seeing errors | From day one |
| Rollback for every release | Undoes a bad release in minutes | From day one |
| Queues and retries around outside services | A slow partner doesn’t freeze your product | As soon as you depend on a partner’s data or payments |
| Status page and incident template | Tells customers what’s happening before they ask | Before you sign your first SLA |
One rule matters as much as any server: the error budget. The example error budget policy in Google’s SRE workbook says that when a service has used more than its budget over the past four weeks, the team halts all changes and releases except urgent fixes and security fixes until it’s back within target. Write a rule like that before the first bad month, while nobody is arguing about deadlines.
The steps people follow matter too. The Uptime Institute’s 2025 outage analysis found that nearly 40% of organizations had a major outage caused by human error in the past three years, and 85% of those came from staff not following procedures or from flawed procedures. Write down how you release, roll back and restore, and use the same steps on quiet days.
Customers don’t care which part failed. If your payment provider, bank feed or email service is down and your product stops, your product is down. The same Uptime Institute report says that over the nine years it has tracked publicly reported outages, third-party IT and data center providers, cloud and internet giants among them, account for about two-thirds.
We hit this on Koncierge, a payment platform for Japan that matches bank deposits to the right customer. The first bank feed relied on a fragile webhook. We moved to a more direct feed that goes through a queue, and moved the validation earlier, so broken or unmappable payments stop before they reach the matching logic. On IPOPBOOKS, a bookkeeping platform for US small businesses, we moved the launch from June 1 to June 16 to test everything with live bank data first. Both platforms run on the client’s own AWS account.
For each outside service, write down what your product does while it’s down. Queue the work and retry it later, or show a clear message and keep the rest of the product working.
Each extra nine is extra work, so price it before you promise it. You can get a free project estimate in four steps:
Uptime is one of the numbers on a SaaS team’s monthly page. The others, from MRR to cost to serve, are in our guide to SaaS metrics for CEOs, CTOs and COOs. The bank feed story is in the Koncierge case study. If you’re planning a SaaS, our SaaS development services page shows how we build one, and our comparison of SaaS development companies helps if you’re still choosing who builds it.
The lowest target your customers will accept, with a tighter target inside the team. A tool used only during office hours may be fine at 99.5% or 99.9%. Products that handle payments or live events need more, and each step up costs more.
About 43 minutes in a 30-day month, or about 8.8 hours in a year. At 99.99% it’s about 4 minutes a month and 53 minutes a year.
An SLO is a target for a measurement, such as the share of requests that succeed. An SLA is a contract that says what happens when you miss it, such as a credit. Google’s SRE book puts it simply: if nothing happens when you miss it, it’s an SLO.
No. The EC2 SLA promises 99.99% per region for instances in two or more Availability Zones, and 99.5% for a single instance. If AWS misses, you get a credit on your AWS bill. Your own product’s uptime depends on how you build and run it.
Post on the status page as soon as you know, update it at set intervals, and fix or roll back. Afterwards, write down what happened and what changes so it doesn’t happen the same way again.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.