What a 99.9% SLA Actually Costs You in Downtime

A 99.9% availability commitment is usually read as a statement about trust. It is closer to a permitted quantity. One tenth of one percent of a year is eight hours and forty six minutes, and a provider that goes dark for eight hours and forty five minutes has met its obligation in full.

The percentage is also only the first of four variables that decide what a customer experiences. The other three, the measurement window, the exclusions and the remedy, sit in a contract annex that almost nobody opens before signing.

Availability is counted by the minute

The conversion is arithmetic. The figures below come from the uptime calculator at uptime.is, which translates any commitment into allowed downtime by reporting period.

Those numbers are allowances, and nothing distributes them evenly across the year. A single long incident can spend the whole budget in one afternoon. A service that fails for nine hours once has breached a 99.9% commitment, while the same service failing for two minutes every working day has not, and the second pattern is often the one customers complain about.

Maintenance, attacks and misuse do not count

Exclusions come before comparison. In OVHcloud’s specific conditions for public cloud services, used here because the document is public and its structure is typical of the market, service credits do not apply to scheduled maintenance, customer misuse, outdated software, third party outages, denial of service attacks or force majeure.

The measurement rules carry as much weight. Unavailability is defined as the loss of access to all instances of the service for more than three consecutive minutes, detected by ARP ping monitoring, and the period is counted from the moment the incident ticket is opened. A four minute failure that nobody reports never happened, as far as the contract is concerned.

What arrives after a breach is a service credit, calculated against the invoice and capped. An SLA is not insurance, and the remedy is shaped accordingly.

The distance between a remedy and a loss is easiest to see in a real incident. On 15 March 2026 the billing infrastructure company Autumn published a post mortem reporting that approximately 10% of API requests failed after a collation migration on two production tables stopped queries from using their indexes, and that the attempt to reverse the change deadlocked against queries already holding locks.

For a company whose product moves other companies’ payments, an hour of failed API calls lands on its customers’ customers.

What an hour of downtime costs is yours to work out

Uptime Institute’s annual outage analysis reports that 57% of respondents to its 2025 survey said their most recent major outage cost more than $100,000, and that for the second consecutive year one in five put the figure above $1 million.

Those respondents are data center operators, so the survey describes the industry that sells availability rather than the businesses buying it, and a twelve person retailer should take the order of magnitude and stop there.

An honest figure for a small e-commerce store starts with gross margin lost per hour, then adds support labor, advertising spend that ran against a dead checkout, refunds and goodwill, and a realistic allowance for customers who never return. A store contributing $800 of margin an hour, carrying $200 an hour of labor and recovery on top, is losing $1,000 an hour, and that is the number to plan against.

An internal tool needs a different sum: affected employees, multiplied by loaded hourly cost, multiplied by the share of their work the outage blocks, plus whatever the stoppage does downstream. A hundred people at $40 an hour loaded, with half their work blocked, comes to $2,000 an hour.

Those inputs are illustrative, and running them is the point, because a service costing $50 an hour to operate can be sitting underneath a process worth forty times that.

Then apply the allowance. At $1,000 an hour, the eight hours and forty six minutes a 99.9% commitment permits comes to roughly $8,800 a year, and all of it falls on the customer, because the provider kept its promise. That is what the percentage is actually describing.

The allowance also compounds. A checkout that needs a 99.9% web tier and a 99.95% database to be up at the same time is only available when both are, so its composite SLA is the product of the two, about 99.85%, or roughly 13 hours a year. Every chained dependency, from DNS to the payment gateway, multiplies the same way.

Either the replica is tested or it is decoration

Google’s site reliability engineering book, the source of much of the industry’s thinking on availability targets, treats a perfect target as a mistake, on the grounds that it is unachievable and that users neither want nor notice it. The chapter on embracing risk puts the limit concretely: “a user on a 99% reliable smartphone cannot tell the difference between 99.99% and 99.999% service reliability”.

Its answer is the error budget, a stated quantity of unreliability a service is allowed to spend in a quarter, which is an SLA allowance with the incentives pointed the other way.

What reduces downtime is architecture. MySQL’s replication documentation lists the benefits replication is designed for, and they are scale out across replicas, running backups from a replica without disturbing the source, analytics on a copy, and local copies for remote sites.

Failover is not on that list. The documentation also states that replication is asynchronous by default, which is the sentence with the most operational weight in it, because a replica promoted after a source failure can be missing the last transactions the source accepted.

A replica shortens recovery time, the RTO. A backup is what survives a deletion, a corruption or a bad migration, and it answers a different question: how much data can be lost, the RPO. Point-in-time recovery (PITR) narrows that loss to the moment before the bad statement rather than the last nightly dump. On a managed MySQL database, both numbers are worth asking for in writing.

The asynchronous gap has a known fix. With semisynchronous replication, the source waits until at least one replica has received and logged a transaction before the commit returns, and MySQL Group Replication goes further by requiring a majority of the group to agree on each transaction’s order. Either way, a promotion no longer drops the last writes silently.

Tested promotion, monitoring, and a restore somebody has actually performed are what turn any of this into availability. Monitoring sets the mean time to detect (MTTD), rehearsed runbooks set the mean time to repair (MTTR), and together they decide how much of the allowance a single incident spends.

The credit capped, the loss still yours

One worked example makes the variables visible together. The product page for ovhcloud mysql lists a Production plan at 99.95% with two nodes and fourteen day backup retention, and an Advanced plan at 99.99% with three nodes, a read replica and thirty day retention.

The contract qualifies both figures. Those rates apply to multi availability zone deployments, and the same specific conditions commit 99.90% for Production and 99.95% for Advanced when the plan runs in a single zone. One deployment decision moves the committed number by as much as the choice between the two plans, and it is worth knowing before a procurement conversation quotes the advertised figure.

Then the remedy. Credits for a month below commitment are calculated as a percentage of the hourly cost per hour of unavailability, and total credits are capped at 30% of the monthly cost of the impacted service. On a $200 monthly bill, the most the contract will return in its worst month is $60.

Set that beside the $8,800 a year a fully compliant 99.9% service costs a business losing $1,000 an hour, and the service credit sits in proportion: a pricing adjustment for a service that underdelivered, and never a mechanism for carrying a business loss.

When comparing providers, five questions matter, in this order:

• What gets measured: the definition of unavailability, the monitoring method and when the clock starts.
• What gets excluded: maintenance, attacks, misuse and third party failures.
• How quickly a failure is detected and recovered, the MTTD and MTTR behind the percentage.
• What architecture is included in the price: nodes, replicas, availability zones and backup retention.
• What the remedy is worth: the credit formula and its cap.

Two figures in this article answer the question in its title, $8,800 and $60. Only the smaller one appears in the contract.