← Useful
19 October 20267 min read
News

Choose web hosting based on impact, not capacity

Category: Hosting and operations. A practical method for defining the right operational level based on downtime, traffic, recovery and responsibility.

Category: Hosting and Operations

Many choose web hosting by comparing storage, processing power and monthly price. These are easy to measure, but say little about how well the operating environment supports the business when something actually happens.

A better starting point is impact: What does it cost if the website is unavailable, slow or displaying incorrect content? How much data can you lose? How quickly must normal operations be restored? The answers provide the basis for a specific operational profile.

Driftskrav bør knyttes til funksjonene virksomheten er avhengig av.
Operational requirements should be linked to the functions the business depends on.

The operational profile is a concise decision document that describes requirements for uptime, performance, caching, CDN, backups, monitoring, maintenance and responsibility. It makes it easier to choose the right hosting and reduces the risk of important needs only being discovered after an incident.

Start with the website’s actual role

Two websites with roughly the same traffic can have completely different operational needs. An information site that mainly displays opening hours and contact details can often tolerate a short interruption. An online store, logged-in customer portal or booking solution can lose revenue and create manual follow-up work during the same period.

Before considering technical solutions, you should answer these questions:

  • What tasks do customers and employees perform on the website?
  • What happens in the business if these tasks cannot be completed?
  • Are there alternative channels while the website is down?
  • At what times of day and during which periods is availability most important?
  • What data is generated on the website, such as orders, forms or user content?
  • Who will make decisions and communicate during an operational failure?

Describe the consequences concretely. “The website is important” is not an operational requirement. “Customers cannot place orders, and customer service must register orders manually” provides a clear basis for prioritisation.

Divide the solution by criticality

It is rarely necessary to impose the same requirements on every part of the website. A campaign page, an online store’s checkout and an internal reporting area can have different needs even if they are part of the same solution.

En kort driftsprofil gjør ansvar og prioriteringer tydelige.
A concise operational profile makes responsibilities and priorities clear.

A simple classification could be:

Standard publishing

This applies to content that can tolerate shorter interruptions and changes relatively infrequently. A standardised, managed operating environment may be sufficient here, provided that backups, updates and basic monitoring are in place.

Business-critical service

This includes active sales pages, forms that generate customer enquiries and solutions employees depend on. Here, requirements for response times, recovery, performance monitoring and supplier responsibility should be more clearly defined.

Mission-critical function

These are functions where interruptions quickly affect revenue, deliveries, customer data or core business processes. Such solutions may require more robust infrastructure, more frequent backups, redundancy and support outside normal working hours.

The point is not to make the entire website as advanced as possible. The point is to use resources where the consequences are greatest.

Riktig driftsmiljø handler om mer enn tilgjengelig kapasitet.
The right operating environment is about more than available capacity.

Define uptime as more than a percentage

A promise of high uptime may seem reassuring, but it must be clearly defined. You should know what is measured, where it is measured from, which parts of the service are included and which interruptions are excluded.

A website may respond technically even if login is failing, product search does not work or the checkout cannot accept payment. The operational profile should therefore describe which functions must work for the solution to be considered available.

Also clarify:

  • Whether planned maintenance counts as downtime.
  • When maintenance is normally carried out.
  • How quickly critical errors should be assessed.
  • Which contact channels apply outside working hours.
  • Who is responsible when the error lies in code, integrations or external services.

This distinguishes a genuine operational setup from a generic hosting product.

Determine what can be cached

Caching reduces the load on the server by reusing already generated content. It can make pages faster and improve capacity during traffic peaks. Incorrect caching can also cause users to see outdated or personal content that is not intended for them.

The operational profile should distinguish between public content and dynamic functions. Articles, images and product pages can often be cached effectively. Shopping carts, checkouts, logged-in areas and personalised prices usually need to be handled differently.

Clarify how the cache is cleared when content is published, products are changed or a critical fix is deployed. There should also be a controlled way to disable caching during troubleshooting. Otherwise, old versions may hide whether a fix is actually working.

Use a CDN when it solves a specific need

A CDN distributes static files and, where applicable, cached content closer to users. It can be useful when the target audience is geographically dispersed, the website contains many large files, or traffic varies significantly.

However, a CDN is not a substitute for a well-run operating environment. Slow database queries, heavy extensions and inefficient application code are not automatically fixed. Therefore, define what the CDN is intended to improve: image delivery, handling traffic spikes, geographic response times or relieving the origin server.

You should also know who manages the settings, how changes are tested and what happens if the CDN service experiences problems. Multiple technical layers only add value when responsibilities and troubleshooting procedures are clearly defined.

Set recovery requirements before backup frequency

“Daily backup” is not a complete requirement. For a website that receives orders throughout the day, losing one day of data could be serious. For a static information site, it may be acceptable.

Define two factors:

  • Acceptable data loss: How far back can you go without the consequences becoming unacceptable?
  • Acceptable recovery time: How long can the service be unavailable while it is being restored?

You can then choose the backup frequency, retention period and recovery method. Backups should be stored separately from the environment they protect. It should also be clear whether the provider restores the entire solution, individual files or the database, and who verifies the result afterwards.

Monitor what users depend on

Server monitoring can show that the machine is running, but not necessarily that the website is working. A professional operations profile should combine several levels:

  • Availability of key pages and functions.
  • Response times and clear deviations from normal performance.
  • Errors in the application, database and integrations.
  • Resource usage such as storage space, memory and processing capacity.
  • Expiration or errors related to certificates and domain configuration.
  • Completion of scheduled backups and maintenance tasks.

Not everything should trigger an alarm to management. The operations provider should filter technical signals, investigate the cause and escalate when the incident requires a decision or affects the business.

Clarify maintenance as an ongoing service

Hosting keeps the infrastructure running. Maintenance ensures that the website itself continues to work as software, integrations and requirements change. These tasks may be handled by the same provider, but this should not be taken for granted.

The operations profile should describe who handles updates, compatibility testing, bug fixes, cleanup and capacity assessments. Also specify which changes can be carried out as routine tasks and which require approval.

For important solutions, changes should first be tested in a separate test environment. The test environment must resemble the production environment closely enough for the results to be relevant, but it should not use real personal data indiscriminately or send actual emails and orders.

Choose the operating environment based on responsibility and needs

Shared hosting, virtual servers, managed platforms and scalable cloud environments can all be the right choice. The difference lies not only in capacity, but also in how much responsibility the business must assume itself.

An environment with many options can become a burden if no one is responsible for configuration, security and bug fixes. A more standardized environment may be better when the provider is familiar with the publishing solution and manages the entire operations chain.

Therefore, consider the following when choosing an environment:

  • Whether the solution has steady or highly variable traffic.
  • Whether the application requires special server settings.
  • How much control the developers actually need.
  • Whether the provider is responsible for the operating system and platform.
  • How testing, production and any backup environment are separated.
  • How easily the solution can be moved or scaled later.

Bring the requirements together on one page

A useful operations profile does not need to be extensive. It can be summarized in the following points:

  1. The website’s most important functions and the consequences of interruptions.
  2. Critical periods and expected traffic peaks.
  3. Requirements for availability and response in the event of errors.
  4. Rules for caching and the use of a CDN.
  5. Acceptable data loss and recovery time.
  6. Functions and technical aspects that should be monitored.
  7. Responsibility for updates, testing and maintenance.
  8. Contacts and decision-making authority during incidents.

Review the profile when the website gains new functions, integrations or significantly higher traffic. A simple website can gradually become a central workspace without the operations agreement being updated accordingly.

Professional web hosting is therefore less about buying as much capacity as possible and more about making informed choices. When requirements are based on the actual consequences for the business, it becomes easier to choose the right environment, allocate responsibility, and pay for the level of service the website actually needs.