The Uptime Budget: What 99.9% Actually Costs to Build

"Ninety-nine point nine percent uptime" appears in almost every software proposal, usually without anyone calculating what it means or what it costs. It means 43 minutes of unavailability per month. Four nines means four minutes — and getting from one to the other is not a configuration change, it is a different architecture and a different operating budget.

Pick the number on purpose. Here is what each tier actually requires.

The tiers, in downtime you can picture

• 99% — 7 hours 18 minutes a month. A single server, backups, someone who notices. Fine for internal tools.
• 99.9% — 43 minutes a month. Redundant application instances, a managed database with automatic failover, health checks, alerting to a real person.
• 99.95% — 21 minutes. Multi-zone, zero-downtime deploys, tested failover, a defined on-call rota.
• 99.99% — 4 minutes 19 seconds. Multi-region, no single point of failure anywhere including DNS and the CDN, automated failover, chaos testing, and people paid to be awake.

Note where the cost curve bends. Moving from 99% to 99.9% is mostly good engineering practice. Moving from 99.9% to 99.99% roughly triples infrastructure cost and requires organisational commitment — a rota, escalation, and the discipline to run drills.

Deploys are the main cause of downtime

Hardware fails rarely. Cloud zones fail occasionally. Changes fail constantly — the large majority of unplanned downtime originates in a deployment.

Which means availability work starts in the pipeline, not in the infrastructure: blue-green or rolling deploys, database migrations that are backwards-compatible so old and new code can run simultaneously, feature flags so a risky change can be turned off without a rollback, and a rollback that has actually been practised. Get this right and you have bought most of the way to three nines without adding a single server. See CI/CD pipelines for the mechanics.

Availability is what your users experience, not what your servers report

A server responding with a 200 while the checkout is broken is not "up". Measure availability from outside, against the journeys that matter: can someone log in, can they complete the core action, can they pay.

Synthetic checks running those journeys every minute from a couple of regions will tell you about an outage before your customers do, which is the entire point. Internal health checks tell you the process is alive; they do not tell you it is useful.

Degrade instead of failing

The cheapest availability win is not redundancy, it is graceful degradation. If recommendations are down, show the catalogue without them. If the search service is unreachable, fall back to a simple database query. If the email provider is failing, queue and retry rather than blocking the signup.

Each of those turns a total outage into a partial one. It costs a day of engineering per dependency and it is almost always worth more than another instance.

What to commit to contractually

If you are selling to enterprises, they will want an SLA, and an SLA is a promise with money attached. Three practical rules: promise a tier below what you actually achieve; define precisely what counts as downtime and what is excluded (planned maintenance, third-party failures, customer network issues); and make the remedy a service credit rather than open liability.

Then publish a status page. Customers forgive outages far more readily than they forgive silence.

An honest recommendation

For most B2B products, target 99.9%, architect so 99.95% is reachable without a rewrite, and spend the money you saved on monitoring and on rehearsing recovery. Mean time to recovery is worth more than mean time between failures: an outage nobody notices for forty minutes is worse than three outages resolved in ninety seconds.

And test your backups by restoring them on a schedule. An untested backup is a belief, not a control — see the handover checklist.

Where to go next

Cloud migration strategy: AWS vs Azure vs Google Cloud covers where to run this, and security basics before your first enterprise deal covers the other half of what an enterprise buyer will ask for.

We build and hand over this setup as part of DevOps and cloud engagements — tell us what you are running today.