SaaS Uptime SLAs: What to Offer Enterprise Customers and How to Engineer 99.99% or Better

Offer an SLA one step below what your architecture has proven it can deliver, commonly 99.9% for standard plans and 99.95% or 99.99% for enterprise plans, with clear measurement and service credits. 99.99% (about 52 minutes and 34 seconds of downtime per year) is hard to sustain end to end in a single region, because one region cannot survive a region-wide outage, and a single 15-hour regional outage uses about 17 years of four-nines error budget. The dependable path is active-active serving across at least two locations plus tested database failover. Control Plane runs a workload active-active across locations under a 99.999% availability SLA for workloads with at least two replicas in at least two locations, and those locations can be on different providers.

Disclosure: Control Plane publishes this guide.

TL;DR

• Pick the SLA. Set your external SLA below your internal SLO. 99.9% is a common enterprise baseline; 99.95% and 99.99% belong on premium and mission-critical tiers. Only promise what your architecture has sustained over multiple months.
• Know the downtime math. 99.99% allows 52 minutes and 34 seconds of downtime per year, or 4 minutes and 19 seconds per 30-day month. A single prolonged incident can exhaust your entire error budget.
• Architect for the tier. Single-region multi-zone survives zone failures but not a region-wide outage. Active-passive multi-region adds recovery time. Active-active multi-region or multi-provider is the dependable path to 99.99% and beyond.
• Test failover regularly. Run game days, drain one location at a time, and rehearse database promotion. Measure recovery time in every test.
• How Control Plane fits. A workload deployed to Control Plane’s Global Virtual Cloud (GVC), a set of locations a workload runs across, runs active-active in every location of that GVC. A global endpoint routes each request to the nearest healthy location, delivering failover without paying for idle standby capacity, under a 99.999% availability SLA for workloads with at least two replicas in at least two locations.

What Uptime SLA Should a B2B SaaS Company Offer Enterprise Customers?

Offer 99.9% on standard enterprise plans and 99.95% or 99.99% on premium tiers, set one step below an internal SLO your architecture has already met.

SLA vs. SLO vs. SLI

These three terms are related but serve different purposes. A Service Level Indicator (SLI) is the metric you measure, such as the percentage of HTTP requests that return a successful response within 300 milliseconds. A Service Level Objective (SLO) is the internal target you set for that metric, for example 99.97% of requests succeed over a rolling 30-day window. A Service Level Agreement (SLA) is the contractual commitment you make to customers, backed by remedies like service credits if you miss it.

Set the external SLA below the internal SLO. If your SLO is 99.97%, offer a 99.9% SLA. The error budget is 100% minus the SLO, here 0.03%, or about 13 minutes per 30-day month. When it runs out, teams slow releases and fix reliability. The gap between the SLO and the SLA is a safety margin, so a missed SLO triggers internal action before it triggers credits.

What to Put in the Contract

A well-drafted uptime SLA needs several precise elements:

• Measurement method and window. Define whether availability is calculated from synthetic health checks, production request success rates, or both. Specify the aggregation period, typically a calendar month or rolling 30-day window.
• What counts as downtime. State whether downtime means the API returns errors, the login page is unreachable, or a health-check endpoint fails. Be specific about which components are covered.
• Scheduled maintenance. Exclude pre-announced maintenance windows from the downtime calculation, and state the minimum notice period, the maximum maintenance time per month, and the allowed time windows.
• Exclusions. Customer misconfigurations, force majeure events, beta features, and failures of services outside your control should be explicitly carved out.
• Service credits. Credits usually increase as availability drops. For example, the AWS EC2 Region-Level SLA credits 10% of the monthly bill below 99.99%, 30% below 99.0%, and 100% below 95.0%. Many SaaS contracts cap total credits at a percentage of the monthly fee.
• Claim process. Specify how customers submit credit requests, the evidence required, and the deadline for claims after an incident.
• Regional scope. State whether availability is measured globally or per customer region. A global average can hide a full outage in the one region a customer uses.
• Partial degradation. Define how elevated error rates, severe latency, or loss of a single feature count. A common approach counts a minute as down when the error rate exceeds a stated threshold.
• Chronic failure. Enterprise buyers often ask for the right to terminate without penalty if the SLA is missed in several months within a set period.
• Credits and liability. State whether credits are the sole and exclusive remedy and whether they count toward the contract’s liability cap. Buyers negotiate both.

Common Tiers

Higher-tier SLAs justify premium pricing because they demand more infrastructure redundancy, tighter operational processes, and faster incident response.

How Much Downtime Does Each SLA Allow?

The table below is computed from 525,600 minutes per year, 43,200 minutes per 30-day month, and 10,080 minutes per week.

At 99.99%, a single five-minute outage wipes out more than a month’s error budget. At 99.999%, you have roughly 26 seconds per month. A human responder usually cannot be paged, diagnose the problem, and act within that budget, so detection and failover have to be automated.

How Do I Achieve 99.99% Uptime for a SaaS Application?

Run active-active across at least two regions with automated health-based routing, give the database a tested failover path, and roll out changes one location at a time.

Composite Availability: Why Dependencies Cap Your SLA

When components are in series, meaning a request must pass through each one, their availabilities multiply. The composite availability formula is:

A_composite = A_1 × A_2 × A_3 × … × A_n

For example, if your API server has 99.99% availability and your database has 99.95% availability, the composite availability is 0.9999 × 0.9995 = 0.9994, or 99.94%. Your database just pulled your system below four nines even though your application tier met it.

Adding redundancy helps. When two components operate in parallel so that the system fails only if both fail, the parallel availability formula is:

A_parallel = 1 − (1 − A_1) × (1 − A_2)

Two instances each at 99.9% yield 1 − (0.001 × 0.001) = 0.999999, or 99.9999%. That result assumes the two fail independently and that failover is instant. Real systems rarely meet either assumption. Replicas in the same region share power, network, and provider control-plane dependencies. Replicas running the same build share the same bugs. Replicas reading the same configuration fail together when that configuration is wrong. Treat the parallel result as an upper bound.

Changes to a live system, meaning code deploys and configuration pushes, are a leading cause of outages; the Control Plane Cloud Outage Tracker attributes 32% of major outages since 2020 to configuration or deployment changes. Redundancy does not protect against a bad change pushed to every location at once. Roll out changes one location at a time, gate each step on health metrics, and keep a fast rollback. Apply the same staged rollout to configuration, feature flags, and DNS changes.

Architecture by Tier

Single region, multi-zone. Deploy across two or more availability zones in one cloud region. This protects against single-zone failures such as power or network issues within one zone. Cloud providers back multi-zone compute with SLAs as high as 99.99% (for example, the AWS EC2 Region-Level SLA), but that covers only the compute layer. Once databases, load balancers, and DNS are multiplied in, end-to-end availability is lower, and the design cannot survive a region-wide outage. Every major provider has had region-level outages lasting hours.

Active-passive multi-region. A primary region handles all traffic while a standby region stays ready. On failure, traffic is redirected to the standby. Recovery time depends on how quickly you detect the failure, promote databases, and reroute DNS. The standby infrastructure sits idle during normal operation, which means you pay for capacity that serves no traffic most of the time. For a deeper comparison, see active-active vs. active-passive cost.

Active-active multi-region. Every region serves live traffic simultaneously. A global load-balancing layer routes requests to the nearest healthy region. When health checks mark a location unhealthy, the load balancer stops sending it traffic. Failover speed depends on health-check intervals, failure thresholds, and DNS TTLs when routing is DNS-based. Surviving locations need enough spare capacity to absorb the lost traffic, and the database still needs its own failover design. It survives a full region outage without a recovery step, which is why it can sustain 99.99% and above. Every location serves production traffic, so no standby region sits idle.

Multi-provider. Running across two or more cloud providers removes the single-provider risk. A region-wide outage on one provider does not affect locations on another. This adds complexity in identity, networking, and deployment but provides the strongest resilience posture. For a detailed breakdown of what each design can deliver, see five nines uptime architecture.

How Do I Fail Over a Database-Backed Application Between Cloud Regions?

Database failover is the hardest part of multi-region resilience. The application tier is often stateless and easy to replicate, but the database holds state that must survive a region failure without corruption or data loss.

Managed Cross-Region Replicas with Promotion

Major cloud databases offer cross-region replicas that can be promoted to primary on failure. Amazon Aurora Global Database replicates to secondary regions with typical lag under one second, and AWS says a secondary region can be promoted to read and write in under a minute. Cloud SQL supports cross-region read replicas that you promote manually, with replica failover and switchover on the Enterprise Plus edition. Azure SQL Database failover groups replicate databases asynchronously to another region and keep the same connection endpoint after a failover. Promotion takes from under a minute to several minutes, depending on the service, replication lag, and DNS caching, and writes are unavailable during that window.

Synchronous vs. Asynchronous Replication

Recovery Point Objective (RPO) is the most data, measured in time, you can afford to lose. Recovery Time Objective (RTO) is the longest the service can stay down before it is restored. Synchronous replication commits a write only after both the primary and secondary regions confirm it. This gives an RPO of zero, but every write waits for a round trip to the remote region, so latency grows with distance. It also ties write availability to the remote region: if the secondary is unreachable, the primary must either stop accepting writes or fall back to asynchronous mode and give up zero RPO. Asynchronous replication commits locally and ships changes to the secondary in the background. Writes are faster, but a failure can lose transactions that had not yet replicated, so RPO is above zero.

Distributed SQL Databases

Databases like CockroachDB and Google Cloud Spanner accept writes from clients in any region and use consensus replication (Raft in CockroachDB, Paxos in Spanner) to commit each write across regions. They provide strong consistency and automatic failover without manual promotion. The trade-off is write latency, because a write commits only after a majority of replicas acknowledge it, and some of those replicas may be in other regions. Surviving the loss of a full region requires replicas in at least three regions.

Fencing and Split-Brain Prevention

When a primary region becomes unreachable, you must ensure it cannot continue accepting writes while the new primary is active. Fencing prevents split-brain, where two nodes both act as primary. Common methods are revoking the old primary’s network access or credentials, powering it off (often called STONITH), leader leases that expire, and fencing tokens, increasing numbers that storage checks so it rejects writes from a stale primary. Leases depend on bounded clock drift, so set lease timeouts with margin.

Connection-String and DNS Changes

After promotion, your application needs to reach the new primary. Strategies include DNS-based failover with low TTLs, connection proxies that abstract the primary endpoint, or application-level configuration that reads the current primary from a coordination service.

How Do I Test Failover Without Taking Production Down?

Test failover in stages. Start in a non-production environment, then move to small, controlled slices of production traffic, with a rollback ready at every step. A failover path that has never been tested often fails when it is needed, and regular tests surface problems such as stale DNS records, expired credentials, and database promotion scripts that no longer work.

Game Days

Designate a scheduled window where your team deliberately triggers a failure scenario and practices the recovery process.

Canary Traffic Slicing

Fail over a small slice of traffic, such as internal users or a single tenant, to the secondary location. Observe behavior, latency, and error rates before committing to a full failover.

Draining One Location at a Time

Remove one location from your load balancer and verify that all traffic shifts cleanly to remaining locations. This tests both the routing layer and the capacity of surviving locations to absorb the additional load.

Synthetic Checks

Run synthetic transactions that exercise critical user flows, such as login, API calls, and data writes, from external vantage points. These catch failures that internal health checks miss, including DNS resolution problems, certificate expiration, and CDN misconfigurations.

Chaos Engineering Tools

Open-source projects like Chaos Mesh and LitmusChaos inject faults into Kubernetes workloads, including pod kills, network partitions, and CPU stress. The major cloud providers offer their own fault injection services: AWS Fault Injection Service, Azure Chaos Studio, and Google Cloud Fault Injection Testing (in Preview). Some of these tools can simulate the loss of a zone or region without an actual outage; for example, AWS FIS includes an AZ power interruption scenario and a cross-Region connectivity scenario that blocks traffic to another region and pauses cross-region replication.

Rollback Plan

Every failover test needs a documented rollback path. If the failover itself causes unexpected issues, you need a way to restore the previous state quickly. Test the rollback too.

How Do I Stop Paying for Idle Disaster Recovery Infrastructure?

Replace the standby region with active-active serving, where every location handles production traffic. Active-passive architectures require a standby region that consumes compute, storage, and database resources while serving no production traffic. You pay for capacity that exists solely to absorb a failover. In many organizations, this standby environment drifts out of sync with production because it receives less attention, fewer deployments, and less testing.

In an active-active design, every location serves live traffic, and when one fails, the others absorb its load. Each location still needs headroom to take that load, but the headroom runs production traffic every day, so it is exercised constantly. The application tier has no cold start and no standby fleet to promote, though the database still needs its own failover design.

On Control Plane, a workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. You get failover without paying for idle standby capacity. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

How Do Financial Services Companies Stay Online During Cloud Outages?

Financial services firms stay online by running active-active across at least two regions, often on more than one provider, mapping every external dependency, and proving recovery with drills they can show regulators. The Control Plane Cloud Outage Tracker documents more than 60 major AWS, Azure, Google Cloud, and Cloudflare outages since 2020. No single region on any provider is immune.

Regulated organizations combine these practices with regulatory requirements:

Multi-region or multi-provider active-active. Running in at least two regions, ideally on different providers, ensures that a single-region failure does not take down the service.

Regulatory expectations. Regulators increasingly mandate operational resilience. The EU’s Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, which applies from 17 January 2025, requires financial entities to identify, protect against, detect, respond to, and recover from ICT-related disruptions. It also requires them to manage ICT third-party risk, including concentration risk from relying on a small number of ICT providers such as cloud providers. Firms must run a digital operational resilience testing program, so recovery capabilities have to be tested as well as documented.

Dependency mapping. Catalog every external service your application depends on, including DNS providers, identity services, payment processors, and CDNs. Understand the availability of each and plan for its failure.

Regular drills. Conduct failover exercises regularly; Google’s Well-Architected Framework suggests quarterly. Measure RTO and RPO in practice, not just on paper. Share results with leadership and regulators.

For a practical guide to surviving a specific provider outage, see how to keep your app online during an AWS region outage.

What Questions Should a CIO Ask Vendors About Cloud Resilience, SLAs, and Multi-Failure Tolerance?

Use this checklist when evaluating infrastructure vendors or SaaS providers for mission-critical workloads:

1. What does your SLA cover? Which services, endpoints, and features are included? Are there components excluded from the availability calculation?
2. How do you measure availability? Is it based on synthetic checks, real user traffic, health-check endpoints, or a combination? What is the measurement interval?
3. What are the credit terms? What percentage of the monthly fee is credited at each availability band? Is there a cap? Are credits the sole remedy, and can I terminate if you miss the SLA repeatedly? Is availability measured per region?
4. How many regions and providers do you operate in? Can my workload run in more than one region simultaneously? More than one cloud provider?
5. How does your failover work? Is it automatic or manual? What is the expected failover time? Is it active-active or active-passive?
6. How do you roll out changes? Do code and configuration changes deploy one location at a time with health gates and automatic rollback? Can a single bad change reach every region at once?
7. How often do you test failover? When was the last test? Can you share results or post-mortems?
8. What are your RTO and RPO? Are these tested values or theoretical targets?
9. Do you depend on a single region or provider? What happens to my workload if that region or provider has a multi-hour outage?
10. Do you publish incident history and post-mortems? Is there a public status page with historical data?
11. How do you handle data durability? Where are backups stored? Are they cross-region? How often are restores tested?
12. What are the exit terms? Can I export my data and migrate away without penalty? What formats are available?
13. Do you have adisaster recovery strategy that addresses multi-failure scenarios? How do you handle simultaneous failures across zones or regions?

How Control Plane Approaches Uptime

Control Plane is the platform for running unbreakable apps and agents. It combines locations on any cloud, neocloud, and bare metal into a single GVC.

A workload deployed to a GVC runs active-active in every location of that GVC. A global endpoint routes each request to the nearest healthy location. Readiness probes, which can be HTTP, gRPC, TCP, or a command, decide when each replica can take traffic. When a location has no ready replicas, the global endpoint routes requests to another healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers, for example one AWS region and one neocloud location joined through Control Plane Managed Kubernetes (MK8s). Disabling a location in a GVC removes its replicas and routes traffic to the locations that remain, which turns a location drain into a one-step game-day test.

Control Plane’s location routing options tune this per GVC. A routing tier sets priority: locations with the lowest tier number serve traffic, the lowest-latency location within that tier wins, and the next tier receives traffic only when every location in the higher-priority tier is unavailable. A latency offset makes a location appear closer or farther in milliseconds, which shifts more or less traffic to it.

During the October 20, 2025 AWS us-east-1 outage, which lasted about 15 hours and affected 100+ AWS services in that region, 20 percent of Control Plane customers had us-east-1 in their GVC. Their workloads were “active and running in healthy locations within 10 seconds,” with no customer downtime, according to Control Plane internal incident telemetry.

Control Plane handles Day 2 operations for you, including autoscaling, Capacity AI right-sizing (Control Plane’s right-sizing of CPU and memory based on historical usage), built-in observability, and security, with no Kubernetes cluster you have to operate. A tamper-proof audit trail records changes made through the Control Plane API, and built-in metrics, logs, and traces cover every location in one place.

Control Plane runs serverless, standard, stateful, and cron workloads on AWS, GCP, and Azure and on Kubernetes clusters you already run, and runs VM workloads alongside them on your own servers, including on premises, turned into managed locations with MK8s. Many teams run Control Plane in a single region of one cloud for its Day 2 operations, and adding another region or provider later means adding a location to the GVC. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code.

Databases still need a replication and failover design, and Control Plane helps there too. Stateful workloads give each replica its own persistent volume, and the Control Plane template catalog deploys databases built to span locations, including pgEdge active-active PostgreSQL with multi-master replication, a PostgreSQL cluster stretched across locations with automatic promotion in a surviving location, and CockroachDB. Pair one with the active-active application tier, in enough locations for the database’s quorum (three for CockroachDB), and both layers survive the loss of a location. Active-active serving with health-based routing removes any single replica, zone, or region as a point of failure for the application tier, and any single provider when the GVC spans providers. See also: how to prevent website downtime.

FAQ

What uptime SLA should a B2B SaaS company offer enterprise customers?

Offer 99.9% for standard enterprise plans and 99.95% or 99.99% for premium and mission-critical tiers. Set the external SLA one step below your proven internal SLO so you maintain error budget headroom. Only commit to an SLA your architecture has sustained over multiple months of production operation.

How much downtime does 99.99% uptime allow per year?

99.99% uptime allows 52 minutes and 34 seconds of downtime per year, computed from 525,600 total minutes in a year. Per 30-day month, that is 4 minutes and 19 seconds. A single extended incident can exhaust the entire annual budget.

How do I achieve 99.99% uptime for a SaaS application?

Deploy active-active across at least two regions with automated health-based failover, redundant databases with tested promotion, zero-downtime deployments rolled out one location at a time, and external synthetic monitoring. Single-region multi-zone architectures struggle to sustain 99.99% end to end because they cannot survive a region-wide outage.

What is the difference between an SLA, SLO, and SLI?

An SLI is the metric you measure, such as request success rate. An SLO is your internal target for that metric. An SLA is the contractual commitment to customers, backed by remedies like service credits. The SLA should always be set below the SLO.

How do I fail over a database between cloud regions?

Options include managed cross-region replicas with promotion, synchronous replication for zero RPO, asynchronous replication for lower latency with non-zero RPO, and distributed SQL databases that accept writes in every region. Fencing mechanisms prevent split-brain, and you must rehearse promotion regularly.

How do I test failover without causing an outage?

Run game days with deliberate failure injection, drain one location at a time to verify traffic shifts cleanly, use chaos engineering tools like Chaos Mesh or LitmusChaos, and test with a canary slice of traffic before full failover. Always have a documented rollback plan.

How does Control Plane deliver 99.999% availability?

Control Plane’s 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, and those locations can be on different providers. Each workload runs active-active in every location of its Global Virtual Cloud (GVC), readiness probes decide which replicas take traffic, and a global endpoint routes each request to the nearest healthy location. During the October 2025 AWS us-east-1 outage, affected customers’ workloads were active in healthy locations within 10 seconds, according to Control Plane internal incident telemetry.

How do I stop paying for idle disaster recovery infrastructure?

Use an active-active architecture where every location serves live traffic instead of active-passive where standby capacity sits idle. On Control Plane, workloads run active-active in every location of the GVC, so you get automatic failover without paying for idle standby capacity.

What questions should I ask vendors about cloud resilience?

Ask about SLA scope and measurement method, credit terms and caps, number of regions and providers, failover design and test frequency, how changes roll out across locations, tested RTO and RPO, dependency on a single region or provider, incident history and post-mortems, status page availability, data durability, and exit terms.

How can my company avoid being taken down by the next major cloud outage?

Run active-active across at least two regions, ideally on more than one provider. Map all dependencies, test failover quarterly, and monitor from external vantage points. Every major provider has had multi-hour regional outages.

Talk to the Control Plane team or sign up free to try it.

Originally published on the Control Plane blog.