Understanding 99.9% vs 99.99% Uptime

Uptime percentages are downtime budgets wearing a marketing suit. 99.9% sounds almost the same as 99.99% in a slide. In a 30-day operations month they are an order of magnitude apart. If you cannot do the arithmetic, you cannot tell whether a vendor SLA is a serious target or a number that already expired after one bad deploy.

Use the uptime calculator to convert any percentage into minutes. This article shows the reference math Palmate uses in planning conversations, what contracts usually exclude, and what it actually takes to move from three nines to four.

The 30-day month everyone uses

Operations teams conventionally treat a planning month as 30 days. That is 30 × 24 = 720 hours, or 43,200 minutes.

Allowed downtime is (1 − uptime) × window.

Year figures use 365 × 24 × 60 = 525,600 minutes. 99.9% of that is 0.001 × 525,600 = 525.6 minutes ≈ 8.76 hours (often quoted as 8.77 with rounding). 99.99% is 52.56 minutes per year.

These are not Palmate guarantees. They are arithmetic. Leap years and 31-day months change the window slightly; the uptime calculator lets you switch month and year conventions so finance and engineering argue about the same clock.

What 43.2 minutes feels like

43.2 minutes is a failed deploy you rolled back, a certificate that expired because renewal was a calendar reminder, or a host reboot you did not drain. It is not “the site is usually fine.” If you already had a two-hour outage this month, you have spent the 99.9% budget more than twice.

4.32 minutes is a load-balancer fail-over that worked, or a database failover that was tested. It is not a human SSH-ing in to restart Nginx after a phone call. Four minutes is shorter than most “we’re looking into it” Slack threads.

If your business cannot tolerate 43 minutes of storefront downtime in a month, you are not shopping for a cheaper VPS — you are shopping for redundancy, runbooks, and a measured SLO. Shared hosting vs VPS vs dedicated and VPS vs cloud hosting are about where the boxes live. Extra nines are about how many failure domains you paid to eliminate.

SLA language eats nines

Vendor SLAs often:

• Exclude announced maintenance. A four-hour window every month can be “compliant” while your customers saw a closed shop.
• Measure only their network or hypervisor, not your application, disk full, or a bad release.
• Credit a percentage of the invoice, which may be smaller than the revenue you lost.
• Require you to file within a deadline, with logs they define.

Read the definitions of “unavailable.” Synthetic ping from one region is not the same as “checkout completed.” If you sell availability to your customers, your contract with a host is not automatically your contract with them.

Planned work still consumes user-visible downtime unless you have a pattern that avoids it (blue-green, rolling, a second region). The calculator is mathematical; the contract decides what counts.

How people fake four nines

Measuring from inside the same VM, excluding “degraded but up,” or resetting the month after an incident will produce a prettier percentage. So will counting only business hours.

An honest SLO names:

• The indicator (e.g. successful HTTP 2xx/3xx from an external probe on /health and a canary transaction).
• The window (30 days rolling is common).
• The error budget (the downtime you are allowed to spend on deploys and risk).

Error budgets are how you decide whether to ship on Friday. If 99.9% is the target, 43.2 minutes is the budget — including your own changes.

What extra nines actually cost

Moving from 99.9% to 99.99% is not a checkbox in a panel. Typical ingredients:

• More than one availability zone or a documented, tested failover.
• Managed or replicated data stores, with a restore drill that meets the RTO.
• Deploys that do not require a full outage.
• On-call that can respond inside the remaining minutes, not next morning.
• Dependency mapping: your four nines die if the DNS host, the email API, or the payment processor has none.

A single VPS with Docker Compose can be operated well — see the containerised VPS sample — and still be a single failure domain. That architecture is about repeatable deploys and backups, not a 99.99% claim. Palmate will not invent that number for a sample.

Cloud and DevOps is the service for instrumenting a target that matches budget. The honest conversation is: what does an hour of downtime cost, and what are you willing to spend every month to buy it down?

Application uptime is not host uptime

The VM can be up while the app is wedged, the database is locked, or a third-party auth provider is down. Conversely, you can fail a host health check during a zero-downtime deploy if the probe is too naive.

Capacity matters: a site that dies at peak is “down” for users even if the average over 30 days still looks like 99.9%. Percentages without a definition of request success are decoration.

A practical way to choose a target

1. Estimate the cost of one hour of user-visible failure (orders, support load, contractual penalties).
2. Convert candidate percentages with the uptime calculator.
3. Ask whether you have the people and architecture to spend the remaining budget on purpose (deploys) rather than on accidents.
4. Write the SLO in a runbook. Review it after the first real incident.

99.9% (about 43.2 minutes per 30-day month) is a serious operations target for many business apps. 99.99% (about 4.32 minutes per 30-day month) is a different product: redundancy, practice, and money. Neither is a personality trait of a hosting brand. Both are clocks. Set them on purpose.

Authoritative References & Standards

To cross-reference the engineering patterns and regulatory considerations described in this guide, consult the following authoritative industry documentation and RFC standards:

• Official Docker Documentation — Container runtime specifications, compose file schemas, and multi-stage build best practices.
• PostgreSQL Documentation on Disaster Recovery — Continuous archiving and Point-in-Time Recovery (PITR) guidelines.
• Linux Kernel & Systemd Documentation — Architecture reference for modern Linux service orchestration and daemon lifecycle management.