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 actually 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.
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 covers the definition and I will not repeat it here. What follows is the buying decision.
Redundancy is the cheap part of high availability
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 actually 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: 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, and 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 guarantees in that tier generally land around 99.95 percent, and the price reflects the standing cost of keeping all of that warm, month after month.
Most WordPress outages are not the kind this prevents
This is the part that rarely makes it into 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.
In my experience the outage is almost always a change somebody made on purpose: 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. Redundant infrastructure will replicate every one of those to all four of your servers, 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 actually restored a backup this year rather than confirming that backups exist. Upgrading the tier is the easy half of that, and in my experience 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. Everyone says zero. Write down the number you would actually 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 actually cost you. Sometimes that is a straight revenue calculation and it is easy. More often, for the media, education and government buyers I work with, it is not money at all, it is the fact 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. Your traffic peak and your reputational exposure arrive at the same moment, on a calendar you do not control, and that combination is the actual 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 is nearly always service credits, and a credit worth a few hours of hosting is not a serious answer to a launch you lost.
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 actually running high availability will enjoy answering all three.
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.
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. Most teams find the answer is smaller than the proposal. The ones who find it is bigger usually knew already, and now they have the paperwork to prove it upstairs.
Leave a Reply