Business systems / Checklist
Managed hosting: who is looking after each part of your system?
If you pay for managed hosting, you should be able to find out who deals with a failed update or an expired service. The word “managed” on an invoice is too broad to answer those questions by itself.
A business system may depend on a hosting platform, a database, uploaded files and several connected services. Different people can look after different parts. I would want those responsibilities written down before the system becomes part of the working day.
Start with the service you are buying
A managed WordPress plan, a rented virtual server and a hosted application platform can leave different jobs with the customer. Ask your supplier to describe the arrangement in terms of the work it covers.
AWS’s shared-responsibility guidance makes that variation clear. With some services, the customer manages the guest operating system and application. With more abstracted services, the provider manages more of the underlying platform while the customer still manages their data and access.
Use the actual contract and service documentation to settle your own split. A provider looking after its infrastructure does not establish that your bespoke application, plugin or customer account configuration is included.
Source: AWS: shared responsibility model
Name the person responsible for the application
An application can need attention while the hosting platform is healthy. A plugin may conflict with another update, a connected account may lose access or a background job may stop completing.
Agree who maintains the application code and dependencies, who checks updates and who can make a repair. If the developer and host are different suppliers, decide how they exchange evidence when a fault crosses that boundary.
Include any work that needs the business’s decision. A change to the booking rules or staff permissions needs somebody who knows what the system is supposed to do. Keep that contact current as people’s roles change.
Check the scope of backups and restores
Ask which records and files are backed up, how they can be recovered and who performs the restore. A managed database backup does not necessarily cover the uploaded documents the application needs.
Supabase gives one specific example: its database backups include metadata about Storage objects, but not the stored objects themselves. A system using those files needs an arrangement for them as well. Backup and recovery options also depend on the selected service and plan.
Ask for the result of an agreed recovery test and the person responsible for the next one. Our separate backup article goes through that rehearsal in more detail; the hosting agreement should identify who owns the job.
Source: Supabase: database backups
Put a name beside each recurring job
Use a list like this when discussing the plan. The names may be the owner, developer, hosting supplier or another service provider. The answer needs to reflect the arrangement you actually have.
Include what evidence you will receive and what needs a decision from you. That makes the list useful when somebody is away or a different supplier takes over.
| Job | What to agree |
|---|---|
| Platform and server updates | Covered layers, update owner and any application checks required |
| Application maintenance | Code, plugins, dependencies and safe release procedure |
| Data and uploaded files | Backup coverage, recovery owner and restore-test evidence |
| Access and accounts | Who grants, reviews and removes access, with protected recovery arrangements |
| Renewals | Domain, certificate, licences and third-party accounts, including billing ownership |
| Faults and alerts | Who receives them, support hours and how an unresolved incident is escalated |
Agree what happens when somebody reports a fault
Know the contact route and the information that helps the supplier investigate. A page address, time and description of the failed action are more useful than “the website is broken”. Share private records only through the agreed protected support route.
Confirm the support hours and any response commitment for your plan. A reply acknowledging a ticket and a completed repair are different stages. Ask how progress and ownership will be communicated if another provider needs to become involved.
Check which charges or work sit outside the regular arrangement. A new feature may need separate scope even when the existing system is fully maintained. Getting that distinction in writing gives both sides a clearer conversation.
Update the list when the system changes
A new file store or accounts connection adds another dependency to look after. Put its access, renewal and failure checks on the same responsibility list when it is introduced.
Keep the current version with the handover and contact details. If you cannot identify an owner for one of the jobs, ask the supplier to resolve it before relying on that part of the service.
Sources
Checked on 23 October 2026.
- AWS: shared responsibility model
The division of provider and customer responsibilities varies with the selected service, including application, configuration, data and access duties.
- Supabase: database backups
Service and plan-dependent recovery options, and the distinction between database metadata and stored files.