From hosting package to service agreement: Clarify responsibilities before the website goes down

A hosting package gives you a place to run your website. It does not necessarily provide a complete operations service. The difference becomes clear when the website is slow, a certificate expires, an update fails or a backup needs to be restored. In such cases, it is essential to know who detects the problem, who investigates it and who has the authority to fix it.

Before comparing price, storage capacity and the number of processors, you should therefore define operational responsibility itself. The goal is not an agreement with as many technical terms as possible, but a solution where critical tasks have a named owner, an agreed level of oversight and a practical procedure for dealing with errors.

Start with the website’s importance to the business

The right operating environment depends on what happens if the website becomes unavailable or performs poorly. A simple information site has different requirements from an online store, a membership service or a website that receives customer enquiries through forms.

Describe the consequences specifically:

• Does the business lose sales or enquiries?
• Are employees prevented from carrying out tasks?
• Could submitted data or orders be lost?
• Are reputation, customer service or agreed deliveries affected?
• Are there periods when availability is particularly important?

This provides a better basis for decision-making than choosing the largest package “just to be safe”. A website may have modest resource requirements while still requiring rapid troubleshooting because every enquiry is valuable. Conversely, a content-rich website may tolerate a brief interruption if it has few time-critical functions.

Make uptime a measurable requirement

Uptime is often stated as a percentage, but the figure alone says little. You need to know what is measured, where it is measured from and which interruptions are excluded from the calculation. Planned maintenance, for example, may be exempt even if the website is actually unavailable to customers.

Therefore clarify:

• Whether uptime applies to the server, the website or a specific user function.
• How often availability is checked.
• Whether measurements are taken from one or more geographic locations.
• How planned maintenance is announced and recorded.
• What happens when the agreed level is not met.

A server can respond normally while the shopping cart, search or contact form is broken. Business-critical websites should therefore be monitored through the functions users actually depend on, not just with a simple check of the front page.

Allocate responsibility in a simple operations matrix

Many problems fall between the hosting provider, the web agency and the business. The provider may look after the infrastructure, while the agency maintains the content management system. The business, for its part, is responsible for content, users and internal procedures. Without a clear allocation, everyone may assume that someone else is monitoring things.

Create an operations matrix with three pieces of information for each task: who performs it, who approves changes and who is contacted when something goes wrong. The matrix should cover at least:

• Server, operating system and network.
• Content management system, extensions and integrations.
• Domain, name services and certificates.
• Caching and CDN.
• Backups and restoration.
• Monitoring and alerts.
• Security updates and routine maintenance.
• Troubleshooting across code, content and infrastructure.

One person responsible for each task is better than an unclear shared responsibility. Several parties can contribute, but one party must own progress when something happens.

Choose caching based on how content is used

Caching reduces the load by reusing already processed responses. This can make pages faster and improve capacity, but incorrect configuration can display outdated or incorrect content. This is particularly relevant for logged-in areas, shopping carts, personalised prices and forms with dynamic confirmations.

Clarify which layers are used. The browser can store files locally, an intermediary server can store completed pages, and the application can cache data or database queries. Each layer needs rules for what can be stored, how long it is retained and how it is cleared after publication.

Ask for a practical cache-clearing procedure. Editors should know what to do if a change is not displayed. Developers should be able to clear the right parts without unnecessarily removing all caching. After major changes, you should check both anonymous and logged-in user journeys.

Use a CDN for a defined purpose

A CDN distributes static resources and, in some configurations, entire websites from servers closer to users. It can improve delivery times, reduce the load on the main server and absorb some of the traffic during peaks. However, a CDN is not automatically necessary for every website.

Consider where users are located, how large the files delivered by the website are and how uneven the traffic is. A website with mainly Norwegian users and lightweight pages may gain less than an international service with many images, documents or videos.

The CDN must also be included in the operational responsibility. Someone must manage cache rules, certificates, access control, troubleshooting and purging when publishing. You should also know whether the website can temporarily run without the CDN if the service causes problems.

Define backup using two time targets

“Daily backup” is not a complete specification. You need to know how much data the business can afford to lose and how long the website can be unavailable while it is being restored.

An online store with ongoing orders may need more frequent backups than a website that is updated a few times a month. At the same time, having many copies is of little use if no one can restore them quickly or verify that the result works.

The operations agreement should describe:

• How often files, the database and configuration are copied.
• How long the copies are retained.
• Whether the copies are stored separately from the production environment.
• Who can initiate a recovery.
• How data created after the selected backup time is handled.
• How a restored solution is functionally tested.

It should also be possible to restore individual files or database components when appropriate. Restoring the entire environment may overwrite valid changes and new customer enquiries.

Monitor what requires action

More monitoring does not necessarily mean better operations. Alerts that no one assesses have little value. Every alarm should have a recipient, a threshold and an expected action.

A good minimum includes availability, response time, application errors, resource usage, storage space, certificates and successful backup completion. For important functions, monitoring should also verify that key user journeys work.

Clarify who receives alerts outside working hours. If no one is on call, the agreement should not give the impression of round-the-clock response. A realistic service level is better than an extensive monitoring solution without the capacity to follow up.

Maintenance must include testing and rollback

Updates to the publishing solution, extensions and server components reduce risk, but may also affect functionality. Professional maintenance therefore means more than clicking an update button.

A safe maintenance routine should include:

1. Checking known dependencies and planned changes.
2. An up-to-date backup before work begins.
3. Testing in a separate environment when the change carries significant risk.
4. Checking important pages, forms, login and integrations.
5. A rollback plan in case something fails.
6. Documentation of what was changed and checked.

The business should also appoint a contact person who can prioritise between rapid updates and the need for additional testing. This prevents important maintenance tasks from stopping because no one can make a decision.

Compare operating environments based on control requirements

Shared hosting may suit simple websites with standardised needs. Managed hosting may be appropriate when the business wants the provider to handle more of the infrastructure and ongoing operations. A dedicated or cloud-based environment provides greater control and scalability, but also requires more expertise, configuration and cost management.

The choice should not be guided by the technology label alone. Instead, compare the solutions based on customer isolation, access to logs, the availability of a test environment, scaling approach, geographic location, recovery and how much the provider actually manages.

Also consider how easy it is to move the solution. The business should have access to its own data, necessary configurations and an understandable export process. An inexpensive solution can become costly if you later discover that moving requires extensive reconstruction.

Use an acceptance test before considering the agreement delivered

A new operations solution should be tested as a service, not merely confirmed as “up”. Conduct a simple acceptance test before handover:

• Check the website from multiple devices and without logging in.
• Test forms, search, login and any purchasing journeys.
• Confirm that the cache can be purged and that changes become visible.
• Check that monitoring detects an agreed test outage.
• Restore a copy in a separate environment and functionally test it.
• Confirm contact points, notification procedures and authority during incidents.
• Document how the solution can be moved or terminated.

In the end, professional web hosting is less about server size than predictability. When tasks, measurements and responses are clearly agreed, it becomes easier to choose the right operating environment, handle errors and verify whether the service actually delivers what the business needs.