The website loads, but customers cannot complete an order. The hosting provider says the server is running. The application team needs logs, and the owner does not know who should start handling the incident. The gap is not simply in hardware specifications. It is in responsibility.
Before buying server management, ask about the service through actions: who monitors, diagnoses, changes configuration, repairs code and communicates with you? Hosting alone may be appropriate if your own team handles the remaining work. If that team does not exist, the proposal must explain who fills the gap.
Separate infrastructure, operations and application development
A cloud provider offers services with different responsibility boundaries. AWS and Microsoft describe shared responsibility: using the cloud does not transfer every data, identity or application duty to the provider, and customer work varies between infrastructure and managed services. “Hosted in the cloud” is not evidence that every layer is covered.
An operations company may manage environment settings, monitoring and backups, while an application developer fixes a defect in order logic or a slow query. One company may perform both roles, but this should be explicit. Identify the responsible role and delivery party rather than assuming everyone with server access owns every problem.
Use a responsibility matrix
| Work | Agreement needed | Evidence |
|---|---|---|
| Monitoring | Services and functions monitored, and alert recipients. | A test alert reaching an owner with a follow-up action. |
| Updates | Operating system, dependencies and application, including change windows and rollback. | A change record and appropriate pre-production testing. |
| Backups | Included data and files, frequency, retention and storage location. | Success and failure reporting and a verifiable backup. |
| Restoration | Execution and approval owners, target recovery time and data loss. | A documented restore trial in an isolated environment. |
| Incidents | Classification, diagnosis, escalation and coverage hours. | A ticket with an owner, action history and updates. |
| Accounts | Ownership, permissions and access removal when the engagement ends. | An access inventory and reviewable handover route. |
Several parties may share the table. What matters is that no required cell lacks an owner. Add domains, certificates, email and integrations relevant to your environment. State exclusions too: operational support does not silently become the development of new features.
Monitor an important journey, not only the machine
A fictional store may display its homepage normally while its order-confirmation job has stopped. Monitoring only page availability may miss the failure. Ask the company to identify critical functions and explain how their health will be tested without creating real orders or unintended messages.
Discuss alerts for full storage, certificate expiry, failed backups and background jobs according to what you actually run. Alert quantity is not an achievement by itself. Every important alert needs an owner, meaning and response, with a process preventing persistent noise without action.
A successful backup is not a successful restore test
Clarify the backup contents: database only, or uploaded files and configuration needed to operate as well? Where is it stored, who can access it and how is failure detected? A backup file sitting on the same server is not a complete answer to losing that environment.
Agree on a restoration trial in a separate environment and inspect sample records and a core function afterwards. Record the time taken and any discrepancies. A target for acceptable data loss or recovery time needs design and measurement. Writing it in a sales proposal does not alone make it a guarantee.
Define response, resolution and escalation
Start with a scenario: an essential service stops outside your usual working hours. Where is the report sent, who sees it, when does diagnosis begin and who can approve a consequential action? Specify time zone, coverage days and holidays, especially when your team and provider work in different countries.
Acknowledging a ticket, beginning work, restoring service and correcting the root cause are different events. Request definitions for every time commitment in the proposal, including third-party dependencies and update arrangements. Cloud infrastructure availability and an operations company's commitment to your application also have different scopes.
Review operational access and account ownership
Know who owns hosting, domain and backup accounts and how the operations team accesses them without everyone sharing personal accounts. Discuss permissions by role, change records and access removal when the relationship ends. Effective support does not require giving every person unrestricted access.
Ask how sensitive information is handed over and what appears in reports and tickets. A report can explain an incident and its response without copying access keys or customer information. When changing providers, an inventory of assets, access and documentation should help the new team continue.
Understand what changes the bill
Separate cloud-resource charges from operational fees and major changes. Ask how additional resources or paid services are approved and who receives cost alerts. Clarify whether an upgrade, environment migration or deployment-system rebuild is included or estimated as a separate project.
If a proposal promises “unlimited” resources, request the actual operating limits and usage policy. Do not base the decision only on processor and memory specifications. The service you need also depends on detecting problems, restoring operation and understanding what happened.
When discussing cloud and DevOps services, send an application and critical-function inventory alongside the responsibility matrix. If you are still selecting a migration approach, read the cloud migration guide. Choose coverage you can explain and establish an owner for every part your operation requires.
References and framework limits
The AWS shared responsibility model and Microsoft cloud responsibility guidance were checked on 3 November 2026. They support the general principle that responsibilities vary by service. The matrix and scenario are original operational and purchasing questions, not a legal interpretation of a provider's contract. This text was prepared with AI assistance and review of its content and sources.
