Every care-plan contract I have read in the last year promises uptime. Most of them promise 99.9%, a few promise 99.99%, and almost none of the agencies writing them have checked what their own host promises them. That gap is where the money goes when a client's shop is down for an afternoon and the contract says you owe something.
This post is the arithmetic: what each number means in minutes, what shared and VPS hosts actually commit to on paper, and what you can put in a care-plan agreement without betting your margin on a server you don't run.
What the number means in minutes
Uptime percentages hide the only figure the client cares about, which is how long the site can be down before you've broken your word. Take a 30-day month, which is 43,200 minutes:
- 99% uptime allows 432 minutes down, which is 7.2 hours.
- 99.5% allows 216 minutes, or 3.6 hours.
- 99.9% ("three nines") allows 43.2 minutes.
- 99.95% allows 21.6 minutes.
- 99.99% ("four nines") allows 4.32 minutes.
The jump from 99.9% to 99.99% is not "a bit better"; it is ten times less tolerance, from a long lunch to the time it takes to restart PHP-FPM. And one bad incident eats the whole month. A plugin update that white-screens a site for 50 minutes on a Tuesday means 99.9% is already gone for that site, regardless of how perfect the other 29 days were.
What your host promises you (and what they pay out)
Before you promise a number downstream, read the one you're getting upstream. I went through three published SLAs in October 2026.
WP Engine's SLA commits to 99.95% availability, with a 99.99% tier under an "Enhanced SLA". The credit is 5% of the monthly fee for each full hour of downtime beyond the target, capped at 100% of the month's fee, and you have to open a support claim within 30 days (SLA page, checked October 2026). Kinsta's SLA is 99.9% unless your order form says otherwise. Credits start once downtime passes 43 minutes in a month: 5% for 43 to 59 minutes, 10% for 60 to 119 minutes, 15% for 120 to 179, 20% for 180 to 239, scaled by the share of your sites affected, claimed in writing within 30 days (SLA page, checked October 2026). Hosting.com's uptime commitment is 99.9% measured monthly, 5% of the service fee per hour of unavailability once unscheduled downtime passes 0.1% of the month, applied to future invoices only after you open a ticket and support confirms it (checked October 2026).
Now the exclusions, which matter more than the headline. All three exclude scheduled maintenance. WP Engine's maintenance windows are six hours a day per region; Kinsta's is 2am to 5am daily in the data centre's time zone, and Kinsta decides "at its sole discretion" whether an event counts as downtime at all. All three exclude force majeure, outages at external providers, and anything caused by you or your configuration. Hosting.com also excludes DDoS attacks and any problem between the visitor's ISP and the data centre. The credit is based on the host's own monitoring, not yours.
Do the sums on a real plan. A $35-a-month managed plan that is down for one hour beyond target earns a 5% credit: $1.75. If your care plan for that site is $150 a month and your contract promises a 10% credit for missing 99.9%, you owe $15. You have taken on roughly nine times the host's liability for an outage the host caused. Fine if you priced it in; a surprise if you copied the number from a template.
Shared hosting: what you can honestly promise
On shared hosting you control the WordPress install and nothing underneath it. A neighbour's cron job, the host's PHP upgrade, a disk filling on a box you have never seen: all of it is your downtime and none of it is your fault.
The honest promise on shared hosting is not an uptime percentage. It is a response commitment: "we detect downtime within two minutes, we start work within 30 minutes during business hours, and we report every outage over five minutes to you with cause and fix." You can keep that promise every month because you control every part of it. If a client insists on a percentage, pass through the host's own number with the host's own exclusions, and put the host's credit terms in an appendix so the client sees where the ceiling is. If the site matters more than that, the answer is to move it, not to sign a bigger number.
VPS: what changes, and what doesn't
On a VPS (or a managed layer on top of one, like a Cloudways or RunCloud setup) the host's SLA shrinks to the hypervisor, the network and the power. Everything above that, including nginx, PHP, MariaDB, Redis and the firewall, is yours. Most WordPress outages live in exactly that layer, so you can now fix them instead of waiting on a ticket; you are also the one who gets paged at 3am, and "the host's uptime was 100% this month" will be true while the site was down for two hours because MariaDB ran out of memory.
What you can promise on a VPS is a real 99.9% for a well-run site, provided three things are true: you have automated restarts for the services that fall over, your update process makes a restore point and can roll back without a human, and someone is actually on call outside office hours. Without the third, promise 99.9% measured during business hours and say so. Four nines on a single VPS is not a promise, it is a hope; one kernel patch with a reboot takes most of your monthly allowance on its own. A credible 99.99% means redundancy you are not getting at $20 a month.
You can't promise what you can't measure
The second quiet failure in most contracts is the monitor. A checker that pings every five minutes can miss a four-minute outage entirely, and will log a nine-minute outage as "five". At that resolution you cannot tell a client whether they got 99.95% or 99.9%, and you certainly cannot defend a credit dispute. A 60-second check interval is the floor for any promise tighter than 99.9%, and it needs a confirm-and-recheck step, otherwise one dropped packet becomes a false alarm at 2am and your team stops trusting the alerts.
Measure from outside the host's network, keep the raw check log for at least the contract's claim window (30 days, since that is what the hosts give you), and include SSL and domain expiry in the same monitor; an expired certificate is downtime to the visitor whatever the server says. We covered the expiry side in SSL expiry, domain expiry, DNS drift: the outages nobody monitors, and the honest limits of single-region checking in the multi-region uptime post. For what it's worth, WPClientHub's uptime checks run every 60 seconds with confirm-and-recheck and monitor SSL certificates alongside, from a single region today.
The clause that holds up
The clause I would sign has five parts. State the target and the measurement period ("99.9% per calendar month"). Say who measures and how ("our external monitor, 60-second interval, outage counted after a confirmed recheck"). List the exclusions explicitly: scheduled maintenance with 48 hours' notice, outages caused by the client's own changes, DNS or domain lapses the client controls, and upstream host or network failures beyond your control, with the host's own SLA attached. Define the remedy as a service credit against the next invoice, capped at that month's fee, claimed within 30 days. And put a response commitment next to the percentage, because that is the one the client will actually feel.
Then price it. A 10% credit on $150 is $15; one bad month a year spread over twelve is $1.25 a month. Add it to the tier. The agencies that get burned by SLAs are not the ones who promised 99.9%; they are the ones who promised it for free.
Where this leaves you
Read your host's SLA before you write your own, pass through its exclusions, and promise response times with the same confidence you promise percentages. Then make sure the monitor behind the contract can actually see a four-minute outage. If you want 60-second checks with confirm-and-recheck across every client site in one place, free for 3 sites, paid plans from $19/month, start with your three flakiest sites.