Managed hosting assigns specified maintenance tasks to the provider. It does not automatically mean that every application change, plugin conflict or development request is included. Confirm the responsibility for each important layer of your service before relying on it in production.
IN THIS ARTICLE
01 Map the work to an owner
Separate the network, physical or virtual server, operating system, control panel, website application and business data. Our product descriptions and formal terms define the relevant scope. A self-managed application can run on a managed server, so the word managed needs context.
- Review your service description and management agreement. Identify the operating-system, security-update and control-panel tasks included.
- Ask who updates the CMS, plugins, themes and custom code. Confirm responsibility for testing application compatibility after updates.
- Identify who monitors availability and responds to an alert. A monitoring product does not necessarily include automatic incident repair.
- Review backups, retention and restoration responsibilities. Define who checks successful jobs and tests recovery.
- Agree how to request configuration changes and what access you are authorised to use. SSH or a control-panel login is not permission to alter every server setting.
02 Request work clearly
Describe the desired result, affected service, business impact and current evidence. For a software change, include the application's requirement and any relevant vendor documentation. Ask whether the work is included and whether a maintenance window, backup or separate quotation is needed.
03 Example: record responsibilities for one managed website server
Use a simple service record before launch. The entries below are questions to resolve in your agreement, not promises that every Nabtech plan includes these tasks.
| Task | Record the responsible person or team | Evidence to keep |
|---|---|---|
| Operating-system and control-panel updates | Named provider team or server administrator | Accepted management scope and maintenance process |
| Application and plugin updates | Named developer or included application-management team | Testing and rollback arrangement |
| Backup monitoring and restore approval | Technical owner and authorised business approver | Retention, latest successful test and approval route |
During an incident, supply the affected service, time, error and business impact to the relevant owner. Review the record after a plan change, new application or staff departure. This prevents an urgent database recovery decision being delayed because nobody knows who can authorise replacing newer data.
What happens during an incident?
The provider can investigate the layers it manages, while an application developer may need to repair code or data. Supply timestamps and errors so those responsibilities can be identified quickly. Do not assume that a hosting support response is a guarantee of a particular resolution time.
Keep an internal contact for business decisions such as restoring an older database, disabling checkout or approving a migration. Technical support needs a clear authorised instruction when recovery can replace newer customer data.