Managed Hosting: What to Compare Instead of Benchmarks

Ask ten people what “managed hosting” means and you will get ten answers, most of them about how much the host does for you. That is the wrong axis to compare on, because every managed host claims to do everything.

The two documents that actually distinguish managed plans are unglamorous and almost never read before purchase: the scope of support page and the resource limits page. Both are published. Neither is on the pricing table.

The scope of support is a contract, and it has edges

A well-written scope document tells you both what is included and what is not, and the exclusions are where plans genuinely differ.

One managed WordPress host documents a long inclusion list — caching, automatic core updates, server maintenance and security, a CDN, SSL, staging environments, backups, Git push, SFTP, and a WAF — and then, on the same page, a list of what support will not touch. Their wording:

“Issues with plugin/theme functionality, bugs, and conflicts with WordPress core or your custom code are outside of our scope of support.” The page goes further and says support “cannot assist with custom code, such as CSS, HTML, PHP, or JavaScript.”

Read that twice, because it defines the boundary of the word managed. The host runs the platform. Your site — the thing you are actually worried about — remains your problem. That is a reasonable division, and it is not a criticism of that host; it is simply the shape of the product, and it is the single most useful thing to compare between candidates.

The same page excludes DNS and inbound email from support scope. If you assumed “managed hosting” covered the DNS records that make your site resolve, you now know better.

Automatic updates: check whether rollback exists

Plugin auto-updates are the feature most likely to be advertised and least likely to be described precisely. Two documented details are worth extracting:

Does the host roll back automatically? One provider’s smart update feature documents daily automatic plugin and theme updates with visual regression testing and — the important part — automatic rollback: if an update causes an issue, it “will automatically revert the updates and restore your site to its previous state.”

Compare that with a host that only emails you after an update breaks something. Functionally, the first is a safety net and the second is a notification.

How honest is the feature about its own limits? The same documentation states that visual regression testing “doesn’t guarantee it will always” catch changes, and that the feature “does not guarantee support for premium plugins.” Those two caveats are more informative than the feature list. A vendor that documents the failure modes of its own automation is telling you it has tested them.

The resource caps that survive the word “managed”

This is where a managed plan stops resembling an unlimited one.

Managed WordPress plans are frequently capped by monthly visits, and the caps are documented. One host’s plan tiers run from 25,000 visits a month upward. The same plans cap PHP threads and memory per thread.

Think about what a visits cap actually meters. It is not bandwidth and it is not storage. It is roughly “how much dynamic work we will do for you per month,” and it interacts with everything else: an uncached site burns visits faster than a cached one, and a site with a full-page cache can serve far more traffic under the same cap.

The number on the pricing page is therefore not a traffic allowance. It is a dynamic-request allowance, and the way to buy more of it is caching, not upgrading.

There is a second cap underneath, and reading two pages together reveals it. One host documents its infrastructure as “each custom LXD container is configured with 12 CPUs and 8 GB of RAM,” while its plans cap PHP threads in the range of a few — as low as 2 on entry tiers. The container has twelve cores; your plan is allowed to use the equivalent of a small fraction of one.

That gap is not a scandal. It is how oversubscription works, and every host does a version of it. But it means the hardware specification is not the plan specification, and comparing hosts on vCPU counts is comparing something you will never be allowed to consume.

Why benchmarks measure the wrong thing

Benchmark comparisons of managed hosts measure a request to a freshly installed site, on an idle account, from a location that is not where your readers are. They do not measure:

• What happens when two of your plugins fight after an automatic update
• Whether support answers, and what they are contractually willing to look at
• Where your plan sits against its visits cap in a normal month
• What your site does when it hits that cap

None of those are visible in a benchmark, and all of them are documented in the two pages nobody reads.

What to compare instead

Build a table with the candidates as columns and these as rows:

Row	Where to find it
Included support scope	Documentation, “scope of support” page
Excluded support scope	Same page, usually at the bottom
Automatic update rollback — yes/no	Feature docs, not marketing
Documented failure modes of that automation	Same feature docs
Monthly visits cap, if any	Plan limits page
PHP workers / threads per plan	Plan limits page
Staging included, or a paid tier?	Plan limits page
Where staging sits in the same caps	Staging docs
Backups included, and for which plan sizes	Plan limits page

If a vendor’s documentation does not answer a row, that is a data point. Managed hosting is sold on operational confidence, and a host that has not written down its boundaries is asking you to supply that confidence yourself.

When managed hosting is the wrong purchase

• You enjoy operations. If you would rather tune the stack than file a ticket, you are paying a premium for work you will do anyway — and the “managed” boundary will frustrate you when support declines to look at your custom code.
• Your site is static. A build pipeline and a CDN cover the same ground for a fraction of the cost. Managed WordPress hosting solves a problem that a static site does not have.
• Your constraint is the visits cap. If you are near the ceiling, the cheaper fix is caching, not the next tier.
• You need a runtime nobody supports. See the next article for what “supported” means on the platforms that are not WordPress-shaped.

The category is real and the convenience is real. Just check whether the plan you are buying measures the thing you need — because the pricing page never states which resource it is actually rationing.