Look for eight things in a managed hosting provider, and ask for each one in writing. Four describe the service: a scope boundary, a clear model for who does the work, a severity model with figures, and an availability commitment with a defined remedy. Four describe the risk: backups proven by restore tests, honest compliance wording, data residency terms in the agreement, and exit deliverables.
Provider websites read alike. Managed hosting providers differ in the contract, the service level agreement (SLA) and the evidence they can show. This guide gives a chief technology officer (CTO) or IT director each criterion, how to verify it and the red flag to watch for.
What does a managed hosting provider actually do?
A managed hosting provider runs the infrastructure under your application and takes responsibility for keeping it healthy. The term covers a wide range of offers, so the first task is to name the layer you are buying.
Three layers are commonly sold under the same label.
- Billing and account administration. The provider resells or consolidates cloud accounts and invoices. This layer adds little operational value and is often mistaken for management.
- Infrastructure operations. The provider handles hardening, patching, backups, monitoring, on-call and incident response. This is the layer most buyers mean by managed hosting, managed cloud or infrastructure management services.
- Application operations. The provider deploys your code and runs your release pipeline. This layer needs deeper access and is usually a separate engagement.
A commodity managed WordPress host, such as WP Engine or Kinsta, sells a fourth shape: a fixed platform with public plans, where you manage the site. That model suits many sites. It is a different purchase from an operations contract on your own environment.
Which criteria should you use to compare managed hosting providers?
Each of the eight criteria below can be checked in a document before you sign.
| Criterion | How to verify it | Red flag |
|---|---|---|
| 1. Scope boundary | Ask for a responsibility table: who acts, who approves, who verifies, per function | The provider resists putting scope on paper |
| 2. Who does the work | Ask who opens an alert at night and when senior engineers are engaged | “A senior engineer answers everything”, with no staffing model behind it |
| 3. Severity model | Read the severity definitions and the response figure for each level | Severity levels with no figures, or one figure for everything |
| 4. Availability commitment | Read what the percentage covers, the credit and the exclusions | A headline percentage with no stated scope or remedy |
| 5. Backups | Ask for the date and result of the last restore test | Backup success logs offered as proof of recovery |
| 6. Compliance claims | Ask whose name is on the report being quoted | Wording such as “aligned with SOC 2” and no named report holder |
| 7. Data residency and privacy terms | Find residency, subcontracting and breach notification in the agreement | Residency promised in a sales call and absent from the contract |
| 8. Exit and portability | Ask what documents you keep, and whether a hosting move is required | Runbooks treated as the provider’s internal tooling |
Where does the provider’s scope stop?
Scope is a common source of disappointment in managed hosting contracts. In a typical case, the buyer assumes the provider will handle a failed deployment. The provider assumes deployments are the client’s work. Neither assumption is written down.
Ask for the boundary between infrastructure operations and application operations in plain words. An application that fails because of its own defects is engineering work, and no operations contract fixes it. A good scope document also names the coverage window, the monitored assets and how out-of-scope work is quoted.
For a longer list of diligence questions, the knowledge base has twelve questions for evaluating an AWS cloud management company.
Who does the work when you open a ticket at night?
Ask each managed hosting provider to describe its staffing model for nights and weekends. A credible model for round-the-clock coverage is a trained on-call rotation that works from written runbooks, with senior engineers engaged for the most severe incidents. A runbook is a documented procedure for a known failure.
Be cautious of a promise that a senior engineer personally answers every alert. Covering nights, weekends, vacation and illness takes several people.
Ask which channel is the system of record for response timing. If timing is measured from a ticket, then a telephone call or a chat message may not start the clock. The knowledge base explains the enterprise WordPress support clauses that decide whether support works at 3am.
What does the SLA commit to, and what is the remedy?
A service level agreement contains several different promises. Read four points separately.
Acknowledged response versus resolution. An acknowledged response means a person has received the incident, confirmed it and begun work or escalation. Resolution is the fix. Many providers commit to the first and set a target for the second. An automated receipt should not count as an acknowledgement.
Severity definitions. Severity 1 usually means production is down, and Severity 2 means it is degraded. Your support staff will use these definitions, so a non-engineer must be able to read them. The knowledge base covers how to write a severity bar a non-engineer can read.
What the availability figure covers. A percentage can apply to the network, to the infrastructure or to your application. A provider can only commit to availability on layers it controls.
What the credit covers. Service credits usually attach to availability and not to a missed response time. The SLA often names credits as the only remedy, and lists exclusions such as scheduled maintenance and denial-of-service attacks.
Also check whether 24/7 coverage is universal or depends on the plan.
How do you verify backups, compliance claims and data residency?
These three criteria share one test: ask for evidence, not adjectives.
Backups. A backup that has never been restored is an assumption. Ask when the last restore test ran, what was restored and how long it took. In one example scenario with a Canadian legal-tech software as a service (SaaS) company, the initial audit found that a database restore had never been attempted and that no runbooks existed. The knowledge base describes how to confirm that a database restore works. Expect a provider to describe backup practices, and be wary of one that promises zero data loss.
Compliance. A SOC 2 report is an independent auditor’s report on a service organization’s controls. An attestation of that kind belongs to the organization named on it. A datacentre’s report generally covers the physical and platform layers, not the operational controls a provider runs on top. Ask whose report it is and which layers it covers. If your customers require a report held by the provider itself, make that a shortlist filter.
Residency and privacy terms. Residency, subcontracting, breach notification and the return or destruction of data should be written into the agreement. That is what allows your privacy officer to make a determination under PIPEDA, Canada’s federal private-sector privacy law, or Québec’s Law 25 against documented facts. Ask where backups and any standby region live, not only the primary. A separate article covers what to require from a hosting provider for Canadian data residency.
What do you keep if you leave, and do you have to move hosting?
Ask every provider to name what travels with you when you leave. The useful deliverables are a written runbook set and an architecture diagram that describe your environment. If those documents live only in the provider’s internal tools, leaving means rediscovering your own system.
Ask also whether the provider requires you to move hosting. Some providers only manage their own platform, which is a fair model when stated openly. A provider that requires a move is selling a migration as well as operations, so price and plan it as one.
What drives the cost of managed hosting?
Cost follows a small number of drivers, and a provider should be able to name them.
- The number and class of environments, such as production, staging and development.
- Architecture complexity and redundancy, including high availability and a second region.
- Traffic profile and data volume.
- The coverage window: business hours, extended or 24/7.
- The committed response time per severity level.
- The number of monitored assets, sites or servers.
- Project hours, migration work and compliance or residency needs.
Coverage is the driver buyers underestimate, because round-the-clock response requires a staffed rotation. If your customers are asleep when you are, business-hours coverage may be the honest fit.
The pricing structure also sets the provider’s incentive. Per-user pricing belongs to office IT and says little about a production environment. Percentage-of-spend pricing means the provider earns more when your cloud bill grows. Per-ticket pricing can discourage you from reporting problems. A fixed price for a written scope keeps the provider’s income the same whether or not your bill falls. A companion article explains how managed cloud hosting is priced and what moves a quote.
When should you choose a managed hosting provider, and when should you not?
Choose a managed hosting provider under these conditions.
- You run production systems and have no operations team to cover nights and weekends.
- One person holds most of the production knowledge, and nothing is written down.
- Patching, monitoring and restore tests keep slipping behind product work.
- Customers or auditors now ask for evidence of controls that you cannot produce.
Do not buy managed operations under these conditions.
- Your whole footprint is one instance and a storage bucket. A contract is overhead at that size.
- You have a full-time hire’s worth of steady operations work, or your product is the infrastructure. Hire the person. A separate article compares hiring a DevOps engineer with outsourcing operations.
- Two or more engineers already own operations. Adding a provider splits ownership unless the scope split is explicit.
- Your team is two developers. A one-time pipeline build with documentation may be the right size.
- You run a standard WordPress site. A commodity managed WordPress host with public plans is often the better value.
- You need office IT, an employee help desk or a security operations centre. Those are different categories of provider.
A checklist to take into the vendor call
Ask each shortlisted provider the same eight questions, and ask where each answer appears in writing.
- Where does your scope stop, and can we see it as a responsibility table?
- Who opens an alert at 3am, and which channel starts the response clock?
- Which response times are committed, which are targets, and does 24/7 depend on the plan?
- What does the availability figure cover, what is the credit, and what is excluded?
- When did you last test a restore for an environment like ours?
- Whose name is on the compliance report you mention, and which layers does it cover?
- Where do our data, backups and standby live, and is that in the agreement?
- What do we keep if we leave, and must we move hosting to work with you?
Score each answer on whether it exists in a document.
Where Stack Harbor fits
Stack Harbor is a Canadian-owned managed cloud operations provider (MSP) for production environments, headquartered in Montréal. It serves SaaS companies, agencies and publishers that run production systems without a 24/7 operations team of their own. Its published answers to the eight questions follow.
- Scope. A Managed Cloud Ops engagement covers infrastructure operations, and application operations is scoped separately. Scope is written and signed.
- Who does the work. An on-call rotation works to runbooks designed by senior engineers, and senior engineers own Severity 1. Technical support runs through the support desk. The telephone reaches the account manager.
- SLA. The Stack Harbor SLA commits to 99.9% monthly availability for its own network and infrastructure as a service (IaaS), with a service credit as the sole remedy. Stack Harbor does not guarantee uptime. On plans that include incident coverage, Severity 1 gets an acknowledged response within 15 minutes and Severity 2 within 60 minutes. Resolution is a target, and no credit attaches to a missed response time.
- Compliance. Stack Harbor holds no SOC 2 report and no ISO 27001, PCI DSS or HIPAA certification of its own. The trust and security page separates what suppliers attest from what Stack Harbor operates.
- Residency. Stack Harbor’s own Canadian infrastructure is in two data centres in Montréal. A workload placed there stays in Canada, backups included, and the placement is documented.
- Hosting and exit. Managed Operations does not require Stack Harbor hosting. Every engagement ships with a written runbook and an architecture diagram.
- Pricing. Stack Harbor publishes no prices. It quotes a fixed price for a written scope after an assessment, as described in how Stack Harbor scopes and prices engagements.
Stack Harbor is the wrong fit if you need a provider-held SOC 2 report, technical support by telephone, a public plan grid or office IT. If those four points are not blockers, the next step is a scoping conversation about your environment.
