What managed hosting should actually include, beyond the server

"Managed hosting" can mean almost anything. For one provider it means they keep the server running and you handle everything on it. For another it means they patch WordPress core but not your plugins. The gap between those definitions is exactly where incidents happen: a plugin vulnerability nobody patched, a backup nobody tested, a slow site that the host says is "an application problem". This article gives you a checklist for what managed should cover and the questions that reveal what a provider really does.

Three models, three different promises

The layer-by-layer checklist

Use this to compare what you have today with what you need. For each line, ask who does it, how often, and how you would know it was done.

• Infrastructure: operating system patching, capacity planning, autoscaling, multi-zone redundancy, network isolation.
• Application: CMS core updates, plugin and module updates (including customized ones), PHP version currency, compatibility testing before updates.
• Performance: CDN and page caching, object caching, database tuning, search, load testing before peaks.
• Security: web application firewall, DDoS protection, vulnerability tracking per plugin or module, file integrity monitoring, least-privilege access with multi-factor authentication, encryption in transit and at rest.
• Resilience: automated backups, tested restores, defined recovery time and recovery point targets, a disaster recovery plan.
• Monitoring: 24/7 monitoring of the site and the application, not only the server, with alerts going to a person.
• Change management: Dev, Test, and Live environments, version control, reviewed deployments, documented rollbacks, change freezes around critical dates.
• Accessibility: checks in the release process so updates do not introduce barriers.
• Reporting: regular reviews of performance, security posture, cost, and service levels.
• People: a named team that knows your environment, not a different ticket responder every time.

Questions that reveal the real scope

1. When a plugin or module has a critical vulnerability, who applies the patch, and how quickly?
2. If a plugin has custom modifications, who tests updates against them?
3. When did you last restore one of our backups, and how long did it take?
4. If the site is slow but the server is healthy, whose problem is it?
5. Who is alerted at 2 a.m. when the site goes down, and what do they do first?
6. Can we see the monitoring, the change history, and the incident reports?
7. Are response times written into the agreement by severity, or described as best effort?
8. What exactly is excluded?

The last question is often the most revealing. Every agreement has exclusions. The good ones are specific and short.

Shared responsibility, written down

Even with full management, some things remain yours: the content you publish, who in your organization gets editor access, the accessibility of documents you upload, and decisions about what data the site collects. A clear responsibility matrix, agreed at the start, prevents the "we thought you were doing that" conversation during an incident.

What good looks like in practice

• Updates arrive without drama, because they were tested first.
• You hear about problems from your provider before your users tell you.
• Incidents come with a written explanation of cause and prevention, not only a fix.
• Recurring issues go away rather than being resolved again each month.

Red flags when comparing providers

• "We manage the server, the application is up to you."
• Uptime measured only by whether the server answers, not whether the site works.
• Plugin or module updates described as "available on request".
• No answer to when a backup was last restored.
• A different engineer, starting from zero, on every ticket.

It also helps to agree how the relationship will be reviewed: a regular meeting with trends, incidents, and upcoming work, and a named person on each side who owns it.

How eWay approaches managed hosting

eWay works as a WebOps operator: one team responsible for cloud infrastructure, the CMS application layer, integrations, performance, security, and accessibility, under defined service levels. That includes plugin and module patching with customizations tested in staging, 24/7 monitoring with incidents triaged within 15 minutes, tested backups and defined recovery targets, change control through proper environments, and regular governance reviews. The team you meet at the start is the team that runs your environment year after year.

Next step

eWay customers can open a ticket in the support portal or email support@ewaycorp.com to request a scope review against this checklist. See how to request support for all the options. Related reading: updating WordPress and Drupal safely and Dev, Test, and Live environments. More on our WordPress and Drupal pages.