Order the operational level before the server: How to set requirements for professional web hosting

Category: Hosting & operations

Choosing web hosting often starts with storage space, processing power and price. That is rarely where the most important difference lies. For a business, it is more useful to clarify how critical the website is, how quickly issues must be handled, and how much data the business can afford to lose.

Only when these needs are clear can you assess whether the operating environment, procedures and the provider’s responsibilities are actually adequate. The goal is not to buy as much capacity as possible, but to order an operational level that suits the business.

Start with the consequences of downtime

A presentation website, an online store and a logged-in customer portal have different requirements. If they are all treated the same way, the business often ends up with either unnecessarily high costs or insufficient preparedness.

Therefore, describe what happens if the solution is unavailable for five minutes, one hour and one working day. Consider, among other things:

• Whether customers lose the ability to place orders, pay or contact the business.
• Whether employees are prevented from doing their jobs.
• Whether downtime affects active campaigns or important launches.
• Whether unavailability can damage trust or create extra work for customer service.
• Whether data may be lost while the solution is unavailable.

This assessment provides a better basis for decisions than a general statement that the website must be stable. It also makes it easier to prioritise uptime, response time, recovery and cost.

Make uptime a precise requirement

Uptime is often stated as a percentage, but the percentage alone says little. You need to know what is measured, where it is measured from, and which events are excluded.

Clarify whether availability means that the server responds, that the home page can be opened, or that an important function actually works. An online store can provide a technical response while the shopping cart or payment fails. In that case, the server is up, but the service is not available to the customer.

A useful availability requirement should describe:

• Which pages or functions are to be checked.
• How often the check is to be performed.
• How planned maintenance is handled.
• When an incident is considered to have started and ended.
• Who receives alerts and is responsible for follow-up.
• How uptime and incidents are reported.

Business-critical user journeys should be monitored separately. This could include submitting a form, logging in or making a test purchase up to the payment step. This measures what customers actually depend on.

Determine how quickly you need to be back online

Two requirements are particularly important when something has gone wrong: how long recovery may take, and how much data the business can afford to lose.

Recovery time describes how long the service may be unavailable before it must be back in acceptable operation. Recovery point describes how far back in time data can be retrieved.

A simple business website may be able to be restored from the previous night’s backup. For an online store, this could mean losing orders, customer data or inventory changes. More frequent database copying or a solution that handles transaction data separately may therefore be necessary.

Set requirements for each solution, rather than using one common standard for the entire business. A practical example could be that a content site can tolerate recovery by the next working day, while an ordering solution must be prioritised immediately. The figures must be determined based on real consequences, not on what a standard package happens to offer.

Distinguish between backup and recovery

The fact that a provider takes backups does not automatically mean that the website can be restored quickly. The backup must be complete, available and usable when the production environment has problems.

Ask for clear answers to the following:

• How often files and the database are backed up.
• How long the copies are retained.
• Whether the copies are stored separately from the production environment.
• Whether it is possible to restore a single file, the database or the entire solution.
• Who can request a restoration.
• How long a normal restoration is expected to take.
• Whether restoration is tested regularly.

An unused backup system provides a false sense of security. Therefore, carry out planned restoration tests. The test should document which copy was used, how long the work took, and whether the website worked afterwards.

Define how caching should be managed

Caching can reduce the load on the server and make pages load faster, but it requires clear rules. This is particularly important for solutions with logins, shopping carts, personalised prices or content that changes frequently.

The operating setup may have several caching layers: in the browser, in a CDN service, on the web server and in the publishing solution itself. If no one has an overview of these layers, outdated content may remain available or dynamic pages may be cached incorrectly.

Therefore clarify:

• Which types of pages can be cached.
• Which cookies or logins should bypass the cache.
• How long different resources should be retained.
• How the cache is cleared when content is published or errors are fixed.
• Who can change the rules.
• How you verify that sensitive or personal content is not cached.

Caching should be treated as part of the application's functionality, not merely as a switch the provider turns on.

Use a CDN when the need is clear

A CDN can deliver static resources from multiple geographical locations and reduce traffic to the primary hosting environment. It can also help handle traffic peaks and filter certain types of unwanted traffic.

The need depends on where users are located, how resource-intensive the assets are, and how vulnerable the solution is to high loads. A website with a local audience and few media files has different needs from an international service with a lot of video, images or downloadable content.

The CDN must be part of the operational responsibility. Someone must manage certificates, cache rules, access, troubleshooting and content purging. If the hosting provider and the person responsible for managing the CDN point at each other when something goes wrong, the solution becomes more difficult to operate.

Choose the environment based on responsibilities, not product names

Terms such as cloud, dedicated server and managed hosting do not necessarily indicate who does what. The crucial factor is how responsibility is divided.

For each option, you should clarify who handles:

• The operating system, web server and database.
• Security updates and ongoing bug fixes.
• Content management system, extensions and integrations.
• Capacity scaling.
• Certificates, domain configuration and CDN.
• Monitoring, alerting and incident management.
• Backup, recovery and documentation.

A managed environment may be the right choice when the business wants to purchase both technology and operational responsibility. A more self-service environment may be suitable when the organisation has in-house expertise, sound procedures and the capacity to follow up on incidents. A low server price does not necessarily mean low operating costs if a great deal of work must be carried out internally.

Plan maintenance without turning production into a test environment

Professional operations also involve how changes are implemented. Updates should be tested in a separate environment when they may affect functionality, integrations or customer journeys.

A simple maintenance routine should specify:

1. Which updates can be installed automatically.
2. Which changes require testing and approval.
3. When maintenance is normally carried out.
4. Which checks are performed after the change.
5. How the solution is rolled back if something fails.
6. How affected people are informed.

It should also be possible to handle critical errors without waiting for the next scheduled maintenance window. The routine must therefore distinguish between planned maintenance and emergency changes.

Gather the requirements in an operational matrix

Before choosing a provider or hosting platform, the requirements can be gathered in a short operational matrix. Create one entry for each website or digital service.

The matrix should contain at least:

• The service owner and technical contact.
• The most important user journeys.
• The impact of short-term and prolonged downtime.
• Requirements for availability and response times in the event of errors.
• Acceptable recovery time and data loss.
• Backup frequency and retention.
• The need for caching, CDN and scalable capacity.
• The maintenance window and requirements for a test environment.
• Responsibility for monitoring, alerting and fault resolution.

Use the matrix both when procuring services and as part of ongoing vendor management. This makes it possible to compare alternatives based on actual delivery, not just technical specifications.

Monitor the operational level over time

Requirements change as the website gains more integrations, traffic or importance to sales. Therefore, review the operational requirements after major changes and at regular intervals.

Review incidents, recovery tests, performance issues and planned activities. Also check whether contact details, access rights and responsibilities are still correct. An operations agreement that does not keep pace with the solution gradually loses its value.

Ultimately, professional web hosting is about predictability. The business should know what is being monitored, who responds, how quickly issues are handled, and how the service is restored. Defining this before choosing the server makes the operating environment a deliberate choice rather than an arbitrary technical package.