Most teams need 99.99% availability for authentication, which allows about 52 minutes of downtime per year and is achievable with a well-run single-region high-availability setup. Five nines (99.999%, about 5 minutes per year) requires active-active multi-region architecture and roughly doubles your infrastructure cost. The only common reason to pay for it: your enterprise customers put uptime commitments in their contracts with you, and your authentication SLA flows downstream into theirs.
That is the short version. The rest of this post is the math, the architecture behind each tier, and the questions that tell you which tier you actually are.
The downtime table
Availability percentages sound abstract until you convert them to minutes:
| SLA | Downtime per year | Downtime per month |
|---|---|---|
| 99.9% (three nines) | 8h 46m | 43.8 minutes |
| 99.95% | 4h 23m | 21.9 minutes |
| 99.99% (four nines) | 52.6 minutes | 4.4 minutes |
| 99.999% (five nines) | 5.3 minutes | 26 seconds |
Two things to notice. First, the jump from three nines to four nines removes more than 8 hours of annual downtime. That is the jump most teams should care about. Second, the jump from four to five nines removes 47 minutes. Those 47 minutes are the most expensive minutes in infrastructure.
Authentication deserves a stricter target than most services because it is a multiplier: when auth is down, everything behind it is down too. A 99.9% auth SLA silently caps every application that depends on it at 99.9%.
What each tier costs architecturally
Three nines: a solid single instance
99.9% is what you get from one properly configured Keycloak instance with automated backups, monitoring, and someone who reacts to alerts. Downtime comes from upgrades, instance restarts, and the occasional infrastructure event. For internal tools and early-stage products, this is often fine, and pretending otherwise burns money.
Four nines: single-region HA, done honestly
99.99% requires removing every single point of failure inside one region:
- At least two Keycloak nodes behind a load balancer, in different availability zones
- A database with automated failover (and a tested failover, not a checkbox)
- Zero-downtime rolling upgrades
- Health checks that actually detect the failure modes you have seen
The phrase “done honestly” matters. Plenty of setups look like HA diagrams but fail the first real test because nobody ever killed a node on purpose. If you have never executed a failover, you do not have failover; you have a diagram. Our Keycloak production sizing guide covers the capacity side of this tier.
Five nines: active-active, multi-region
99.999% leaves no room for a region to fail while you react. Both regions must already be serving traffic:
- Active-active Keycloak across regions or clouds, which Keycloak 26.7’s stateless multi-region architecture made a documented pattern instead of a consulting engagement (the official Keycloak high availability guide covers the building blocks)
- DNS-based failover with low TTLs
- Synchronized databases across regions, which is where most of the real engineering lives
- Failover drills on a schedule, because an untested failover path decays
The cost is not just infrastructure that roughly doubles. It is the permanent complexity tax: every change now happens in two places, every incident has two possible origins, and database synchronization becomes a discipline of its own.
The downstream SLA pattern
Here is the pattern that legitimately justifies five nines, and we see it regularly in B2B SaaS.
A software vendor sells to large enterprise customers. Those customers demand 99.99% or better in their contracts. The vendor’s authentication sits in front of every login their customers make, so whatever SLA the auth layer has becomes the ceiling for the SLA the vendor can sign. The auth uptime is being resold downstream.
In that position, paying for the last nine is not gold-plating. It is margin protection: SLA penalty clauses are usually a multiple of what the extra infrastructure costs. One hospitality software company we spoke with carries four nines contractually today and wants five nines specifically for its largest customers, priced as a premium tier of their own product. That is the right way to think about it: the last nine is a product feature you sell, not an engineering vanity metric.
When the last nine is theater
Just as often, the five-nines requirement appears in an RFP because someone copied it from a template. Signs the last nine is theater for you:
- The users behind the login are internal staff who will retry in a minute
- No customer contract of yours contains an uptime commitment
- Your recovery time objective was never actually written down
- The rest of your stack is single-region anyway, so auth surviving a region loss saves nothing
If any of those describe you, a warm standby usually fits better: a synced replica in a second region that takes over in minutes rather than seconds, at a fraction of active-active cost. You trade about 47 minutes of theoretical annual downtime for roughly half the bill and complexity.
Measure before you buy
Whatever tier you target, instrument it. Keycloak ships health and metrics endpoints on the management port, so proving your availability is a probe away:
# readiness and liveness (management port, default 9000)
curl -s https://auth.example.com:9000/health/ready
curl -s https://auth.example.com:9000/health/live
# Prometheus metrics for latency and error-rate SLIs
curl -s https://auth.example.com:9000/metrics | grep http_server_requests
Wire those into your uptime monitoring and compute your real availability for the last 12 months before paying for a higher tier. Teams are often surprised in both directions. If you are on managed hosting, your provider should surface this for you: Skycloak exposes cluster health, request metrics, and alerting in the Insights dashboard, and the IAM ROI calculator helps price the self-hosted-vs-managed side of the same decision.
How to decide in practice
- Read your customer contracts, not your ambitions. What uptime have you promised anyone in writing? That number, plus margin, is your target.
- Write down RTO and RPO. If recovery within 5 minutes with 15 minutes of data loss is acceptable, warm standby delivers it. If the answer must be “no perceptible outage,” you are buying active-active.
- Price both tiers before committing. Get real numbers for four nines and five nines. The delta is often the entire budget of another engineering initiative.
- Check the SLA fine print. A provider’s “99.99%” means little without looking at how it is measured, what is excluded, and what the penalty is. Our guide to negotiating identity service SLAs covers the contract side.
FAQ
What SLA does managed Keycloak hosting typically offer?
Managed providers commonly offer 99.9% to 99.99% depending on cluster tier and contract. Skycloak’s enterprise tier carries a 99.99% SLA, with active-active multi-region setups available when five nines is a genuine requirement.
Does Keycloak support active-active multi-region deployments?
Yes. Since Keycloak 26.7, the stateless architecture supports active-active multi-region and multi-cloud deployments with DNS failover and synchronized databases. Before that, multi-region setups relied on cross-site replication configurations that were significantly harder to operate.
Is five nines possible with a single cloud provider?
Mostly, using multiple regions of one cloud. But a single-cloud control plane remains a shared dependency; the strictest deployments run active-active across two clouds so no single provider event can take authentication down.
What usually breaks the SLA in practice?
Rarely Keycloak itself. Certificate expiry, DNS issues, database failover misconfiguration, and upstream identity providers cause most authentication downtime. The last nine is won or lost in the plumbing around Keycloak, not in Keycloak.
Want the four-nines tier without building it? Skycloak’s managed Keycloak hosting carries a 99.99% SLA on enterprise plans, with active-active multi-region available when you genuinely need the fifth nine. See pricing.