What Is Server Uptime, and What Do the Nines Actually Cost?

Uptime is the percentage of time a service is available. The number looks small in either direction, which is why it is quoted in nines: 99.9% allows about 43 minutes of downtime a month, while 99.99% allows about 4. The gap between those two is the difference between a routine maintenance window and an architecture that has to survive one.

What each nine actually costs you

Uptime	Per month	Per year	What it implies
99%	7h 18m	3d 15h	No redundancy; failures resolved manually
99.9% ("three nines")	43m	8h 45m	Single well-run server, reboots included
99.95%	21m	4h 22m	Some redundancy; fast, practised recovery
99.99% ("four nines")	4m 22s	52m	Automatic failover; no single point of failure
99.999% ("five nines")	26s	5m	Multi-region, automated everything, expensive

Read the second column carefully. A single server that reboots monthly for a kernel update, taking two minutes each time, is already outside 99.99% before anything has gone wrong.

The measurement is not what you think

Three questions decide whether an uptime figure means anything:

• Measured from where? A server that responds on localhost while the upstream network is down is "up" by the wrong definition. Measure from outside, from several regions.
• Measured how often? A check every five minutes cannot see a 90-second outage. Sub-minute intervals catch what matters.
• What counts as up? A machine that answers TCP but returns HTTP 500 is down for every user and up on most monitoring dashboards. Check a real endpoint that exercises the database.

# a health endpoint should test the dependencies, not just the process
GET /healthz  ->  200 only if the database and cache both answer

Reading an SLA honestly

An uptime SLA is a billing term, not an engineering guarantee. Three things to check before you weigh one:

1. What is excluded. Scheduled maintenance is almost always excluded, and it is downtime to your users regardless of what the contract calls it.
2. What the remedy is. Usually a service credit proportional to the outage — a few euros against however much the outage cost you. Credits do not insure your business.
3. Who must claim. Many SLAs require you to notice, document and submit a claim within a window. Unclaimed credits are not paid.

None of that makes SLAs worthless — they signal what a provider is prepared to stand behind. It does mean an SLA is not a substitute for designing for failure.

What actually causes downtime

In roughly descending order of frequency for a small deployment:

• Deployments. Your own changes are the single most common cause. Staging environments and rollback plans address this, and nothing else does.
• Resource exhaustion. A full disk, memory pressure invoking the OOM killer, connection pools running out. All of them predictable with monitoring and all of them preventable — the performance guide covers the limits worth setting.
• Expired certificates. Entirely avoidable, and they always expire on a weekend.
• Traffic spikes and attacks. See DDoS attacks and how to protect your server.
• Hardware and infrastructure failure. Real, but far less frequent than the four above.

The point is that most downtime is self-inflicted and therefore addressable without spending more on hosting.

Getting from one nine to three, cheaply

These cost time rather than money and produce the largest improvement:

• External monitoring with alerts. You cannot fix what you learn about from a customer.
• Automatic restarts. Restart=always in a systemd unit turns a crash into a two-second blip.
• Resource limits. Cap memory per service so one runaway process cannot take the machine.
• Log rotation and disk alerts. A full disk is the most avoidable outage there is.
• Automated certificate renewal, verified. Check the timer exists; do not assume.
• Tested backups. Recovery time is part of availability — see automating backups.

Getting to four nines requires architecture

Beyond three nines, a single machine cannot get you there — a reboot alone exceeds the annual budget. You need more than one instance behind a load balancer, a database with a replica and a failover plan, health checks that remove a bad instance automatically, and deployments that roll rather than restart.

This is where several smaller instances beat one large one. Three €10 Core instances across hosts survive a failure that takes a single €30 Apex offline, and cost the same. It is also where hourly billing helps: bringing up replacement capacity during an incident is a normal action rather than a purchase decision.

Note the trade-off honestly — a dedicated server gives you more performance per euro, but one physical machine is one failure domain. Availability and raw power are different purchases, and VPS versus dedicated works through when each matters.

Do not over-buy availability

Five nines is genuinely expensive: multi-region deployment, data replication with its consistency problems, automated failover that is itself tested regularly, and the engineering time to maintain all of it. For an internal tool, a blog or a business that operates in one timezone, three nines with a fast recovery is the right target and the money is better spent elsewhere.

Decide by asking what an hour of downtime actually costs you. If it is a few missed enquiries, do not build for four nines. If it is thousands in lost transactions, three nines is already too loose.

Frequently asked questions

What is a good uptime percentage?

99.9% is the realistic target for a well-run single server and is adequate for most businesses. 99.99% requires redundancy. Anything above that requires a distributed architecture and a budget to match.

Does scheduled maintenance count as downtime?

Contractually, usually not. To your users, always. Track both numbers.

How do I measure my own uptime?

External checks from multiple regions at sub-minute intervals against an endpoint that exercises your dependencies. Anything measured on the server itself is measuring the wrong thing.

Is a dedicated server more reliable than a VPS?

Not inherently. One machine is one failure domain either way; a VPS fleet spread across hosts is more resilient than a single dedicated box, and a single VPS is no more resilient than a single server.

The practical summary

Measure from outside, understand what your SLA excludes, fix the self-inflicted causes first, and only then buy redundancy. Our VPS plans deploy in under a minute across twelve locations, which makes spreading a workload across failure domains a five-minute exercise rather than a project.