What high-availability WordPress actually requires (and how to tell if you need it)

A hosting quote lands on your desk with two numbers on it. One is roughly what you pay now, the other is three or four times that, and the line item explaining the gap says high availability. Someone on your team asked for it, or a vendor put it in the proposal, and now you have to decide whether that gap is insurance or upsell. You have maybe a week, because the contract renews, and nobody in the room can tell you in plain language what the extra money buys.

I have sat on both sides of that quote. I ran WordPress VIP environments through Postmedia's network migration in 2011 and 2012, eleven newspapers moved onto one parent theme, the National Post and the Ottawa Citizen and the Montreal Gazette among them, and I ran Inside BlackBerry on VIP for three years after that. Later I founded a shop called Rodonic with a dozen full-time developers where most of the client list was broadcast media and digital publishers, which is a polite way of saying every customer we had would tell you, usually in the first meeting, that uptime was not negotiable. Some of them were right about that. A fair number were not, and the ones who were not spent money they could have put into the newsroom.

The short version

So here is the honest shape of the decision, before anybody draws you an architecture diagram. High availability is not one thing you buy, it is a set of guarantees you pay to maintain forever, and whether it is worth it comes down to two numbers you can work out yourself in an afternoon. If you already know what high availability is in the technical sense, the glossary entry on WP high availability covers the definition and I will not repeat it here. What follows is the buying decision.

• You need high availability if your busiest hour of the year is scheduled and public, and someone else picks the date.
• You probably do not need it if your traffic is broadly flat and a bad hour costs you a few hundred dollars and some goodwill.
• The second server is the cheap part. The database replication, shared storage, shared cache, load balancer, and people paid to be awake when it fails are what make the quote jump.
• A second server copies a bad change to every server.
• Work out two numbers first: how many minutes down you could defend the next morning, and what an hour of down really costs you.

What the second server leaves out

Think about a bakery with one oven. If that oven dies at four in the morning, there is no bread that day, and everybody who walks in at seven finds out about it. The obvious fix is a second oven. But the second oven is the least of it. You need floor space for it, another gas line run and inspected, and a second person trained well enough to run it at four in the morning when the first person is off sick. The spare oven costs a few thousand dollars. The building work, the inspection, the extra staffing and the standing gas bill are what change your budget, and they change it every month from now on.

Hosting works the same way, which is why the quote jumps the way it does. Two web servers instead of one is genuinely cheap. What you are paying for is everything that has to exist so those two servers behave like one site.

What high availability requires

• A database that replicates without losing writes.
• File storage every server can reach at the same time.
• A shared object cache, so a logged-in editor does not bounce between two versions of reality.
• A load balancer that notices a sick server before your readers do.
• People who are awake and paid to be awake when it fails on a Sunday at three in the morning.

Enterprise hosts like WordPress VIP, WP Engine Enterprise and Pantheon build all of that in, and the price reflects the standing cost of keeping all of that warm, month after month. The numbers are in the contracts: VIP's SLA commits to 99.95% each calendar month, WP Engine's to 99.95% excluding Excused Downtime, and Pantheon's Multizone Failover add-on, sold on top of Elite plans, to 99.99%.

WordPress's own performance optimization guide says load balancers can spread traffic across multiple web servers but require a higher level of expertise. It also says a persistent object cache saves trips to the database.

What each step closer to 100 percent costs

Google's SRE book chapter on risk says an incremental improvement in reliability may cost 100x more than the previous increment. The Uptime Institute describes Tier II as adding redundant capacity components, and its own description still says an unexpected shutdown of a Tier II data center will affect the system.

Redundancy copies a bad change to every server

This is the part that can be missing from a proposal, and it is the part I would want to know if I were signing. High availability protects you against a component dying. A server falls over, a disk fails, a data centre loses power, and the traffic moves somewhere else without your readers noticing. That is a real category of failure and it does happen.

The introduction to Google's SRE book says its site reliability engineers have found that roughly 70 percent of outages are due to changes in a live system. That is Google's number for Google's own systems. An outage from a change somebody made on purpose looks like this: a plugin update that conflicted with a theme, a deploy that shipped on a Friday, a certificate nobody renewed, a caching rule that started serving a logged-in editor's session to the public, a DNS change made by someone who no longer works there.

What the infrastructure cannot see

Redundant infrastructure will replicate every one of those to every server, instantly and reliably, because as far as the infrastructure is concerned nothing has gone wrong. You have bought a second oven and then run the same bad recipe in both of them.

Which means the first thing worth auditing sits upstream of your hosting tier: your release process, your staging environment, who is allowed to push on a Friday, and whether anyone has restored a backup this year rather than confirming that backups exist. Upgrading the tier is the easy half of that, and it is the half that does the least.

The two numbers that decide this for you

Number one: how many minutes can you be down before it stops being an inconvenience and becomes an incident somebody outside your team hears about. Your CEO will say zero in that meeting. Write down the number you would defend at nine the next morning. For a university marketing site in July, it might be four hours and nobody blinks. For the same university's course registration page on the morning registration opens, it is about ninety seconds before the phones start.

Number two: what does an hour of down cost you. Sometimes that is a straight revenue calculation and it is easy. For the media, education and government buyers I work with, the cost is that the failure is public and the timing is chosen by someone else. Election night. Results day. A minister's announcement. A story that goes wide at eleven at night.

Which side of the line you sit on

Your traffic peak and your reputational exposure arrive at the same moment, on a calendar you do not control, and that combination is the real argument for high availability. If your busiest hour of the year is scheduled and public, buy the redundancy. If your traffic is broadly flat and a bad hour costs you a few hundred dollars and some goodwill, put that money into a tested restore process and better hosting on a single tier, and you will be measurably better off.

What to ask before you sign anything

Ask the vendor to define availability in writing, because the word does a lot of quiet work. Does a page that loads in eighteen seconds count as available? Does a working homepage with a broken checkout count? Do scheduled maintenance windows come out of the guaranteed number, and who picks the window? Ask what the remedy is when they miss it, and read that clause carefully, because the remedy can be service credits, and a credit worth a few hours of hosting is not a serious answer to a launch you lost.

Credits, windows and exclusions

The WP Engine SLA's 99.95 percent allows about 22 minutes of downtime in a 30-day month, and its maintenance windows (10p to 4a Central for the Americas) are excluded. Its remedy is a credit of 5% of the monthly fees for each full hour of downtime in excess of the target. You claim it through support within 30 days, and it is capped at 100% of the month's fees. The WordPress VIP platform SLA excludes outages caused by custom code errors and third-party plugin issues, and pays credits of 5% to 100% of the monthly fee when uptime falls below 99.95%. VIP's exclusions cover custom code errors and third-party plugin issues.

The Amazon EC2 SLA commits to at least 99.99 percent across availability zones and pays a 10 percent credit when uptime falls between 99.0 and 99.99 percent. You file the claim yourself, with request logs that corroborate the outage.

Questions the SLA will not answer

Then ask three practical things that tell you more than the SLA does. Ask for the last twelve months of incident reports, not a summary, the actual reports. Ask who is on call at three in the morning on a holiday weekend and how you reach them, by name of role if not by name of person. And ask what happens to a logged-in user, an editor mid-save, during a failover, because that answer separates hosts who have genuinely tested this from hosts who have only diagrammed it. Any vendor who is really running high availability will enjoy answering all three.

Before the vendor call

Either way, do the two numbers first. Write down your real tolerable minutes and your real hourly cost, take them into the vendor conversation, and make them justify the gap against those figures rather than against a diagram.

The same instinct applies well beyond hosting tiers. If tech is not your job and you would like a general way to see through a technology pitch, that is the wider version of the same two-numbers habit.

Common questions about high-availability WordPress

Do I actually need high availability? If your busiest hour of the year is scheduled and public, an election night, a results day, a registration morning, and someone else picks the date, the redundancy earns its cost. If your traffic is broadly flat and a bad hour costs a few hundred dollars and some goodwill, a tested restore process and steady maintenance on a single tier will do more for the money.

What does high availability cost, and why does the quote jump? The second server is cheap. What you pay for month after month is a replicated database, shared storage, the shared object cache, a load balancer, and people paid to be awake when it fails at three in the morning.

Will it stop my outages? It stops the ones caused by a component failing. It does not stop a bad plugin update, a Friday deploy or an expired certificate, because redundant infrastructure copies that mistake to every server. If that is the failure you keep hitting, a rescue and a better release process help more than a bigger tier does.

Is “highly available WordPress” the same as high-availability WordPress? Yes. Highly available WordPress and high-availability WordPress (sometimes shortened to HA WordPress or WP high availability) describe the same setup: redundant servers, load balancing, and failover so the site survives a server failure. The two numbers that decide whether you need it are further up this page.

One question for you

When high availability last turned up on one of your quotes, who put it there, your own team or the vendor?

If you would rather have somebody independent read the quote and the current setup with you before the renewal date, that is the kind of thing an audit is for, and it is a much cheaper afternoon than a tier you did not need. If that sounds useful, get in touch and we can work the two numbers together.

References

• WordPress VIP Platform Service Level Agreement
• WP Engine Service Level Agreement
• Site Multizone Failover, Pantheon Documentation
• Amazon EC2 Service Level Agreement, Amazon Web Services
• Introduction, Site Reliability Engineering, Google
• Embracing Risk, Site Reliability Engineering, Google
• Tier Classification System, Uptime Institute
• Optimization, WordPress Advanced Administration Handbook

Checked against the WordPress VIP SLA, the WP Engine SLA, Pantheon's Multizone Failover documentation, the Amazon EC2 SLA and the Uptime Institute tier descriptions, on 2026-10-11.