Make Website Operations Measurable: Requirements to Include in the Operations Agreement

Category: Hosting and Operations

A hosting package typically tells you how much storage and capacity you get. It often says less about what actually happens when the website becomes slow, an update fails or customers cannot complete checkout. It is in situations like these that the difference between server space and professional operations becomes clear.

For the business, the goal should be an operations agreement that makes the service understandable and controllable. It must describe what is monitored, who responds, how quickly issues are handled and how the website is restored. Without this, both the customer and the provider may assume the other party is responsible.

Start with the Website’s Actual Importance

Operational requirements should be based on the consequences of downtime and poor performance. A simple information site has different needs from an online store, a booking solution or a website that receives important enquiries.

Clarify, among other things, which functions are business-critical:

• Can customers still contact the business if a form stops working?
• Does revenue stop if the payment solution is unavailable?
• Is the website critical during campaigns, events or specific seasons?
• Is data being processed that requires special controls for storage and access?
• Are there integrations with accounting, inventory, membership or other systems?

The answers provide a better basis for choosing an operating environment than generic labels such as standard, premium or business solution.

Define Uptime Before Discussing Percentages

Uptime sounds simple, but the measurement can be unclear. The agreement should state what is measured, where it is measured from and which failures count as downtime. A server can respond while the homepage displays an error message, the contact form is broken or the online store cannot complete purchases.

A useful agreement therefore describes availability at several levels. The server must respond, the website must deliver valid content and critical functions must work. For an online store, this may mean monitoring product pages, the shopping cart and checkout. For a corporate website, it could include the homepage, a key service page and form submissions.

Scheduled maintenance must also be clarified. Which time windows can be used, how far in advance should the customer be notified and which work can be carried out without prior approval? If these matters are not defined, the uptime figure will be difficult to interpret.

Monitoring Must Lead to Action

Monitoring has little value if alerts are merely collected in a system that no one is watching. The operations agreement should specify who receives alerts, when they must be investigated and how the issue is escalated if the initial action does not resolve the problem.

Good monitoring covers more than whether the server is online. Relevant checkpoints include:

• Response time and availability from outside the operating environment.
• Error codes and empty or incomplete responses.
• Resource usage such as CPU, memory and storage space.
• Certificate expiry or certificate-related errors.
• Background jobs that are not being run.
• Critical user flows such as forms, login or payment.

There should also be thresholds for gradual deterioration. A website can become increasingly slow without going completely offline. Monitoring trends makes it possible to address issues before customers encounter a full service outage.

Describe Caching as Part of the Solution

Caching reduces load by reusing pre-generated content. It can make pages faster and make the website more resilient during traffic spikes. At the same time, incorrect caching can display outdated content, incorrect prices or information intended for another user.

The agreement should describe which parts of the website may be cached, how long content is retained and what clears the cache. Publishing, product changes and campaigns must take effect in a predictable manner.

Dynamic areas require special controls. Shopping carts, checkout, logged-in pages and personalised views should normally not be treated as public content pages. During troubleshooting, the provider must also be able to distinguish between application problems and outdated content in one of several cache layers.

Clarify What the CDN Should Solve

A CDN distributes static files through a network of delivery points. It can reduce load times for geographically dispersed users and relieve the primary operating environment. It can also help handle certain types of unwanted traffic.

A CDN should not, however, be used as a sticking plaster for a slow or incorrectly configured website. If the origin server takes a long time to generate pages, not all requests can be handled at the distribution layer.

The operations agreement should specify who manages the configuration, cache rules and any security features. It must also be clear how the CDN is bypassed during troubleshooting and how content is purged for urgent changes. Unclear ownership can make a simple issue unnecessarily long-lasting.

Set Requirements for Backup and Restoration

Taking backups is not enough. The business must know what is backed up, how often this happens, how long copies are retained and whether they are stored separately from the production environment. A copy on the same system provides poor protection if the entire environment becomes unavailable.

It is useful to distinguish between how much data the business can afford to lose and how quickly the service must be restored. An online store with a continuous flow of orders may need more frequent copies than a website updated a few times a month.

The agreement should also answer practical questions:

• Is restoration included in the operating fee, or is it billed separately?
• Who can request a restoration?
• Can individual files or database data be restored without overwriting everything?
• How is it verified that the copies can actually be used?
• How often is a full restoration tested?

A completed restoration test provides far greater assurance than a status message confirming that the backup job has finished.

Distinguish between server operations and website maintenance

Many conflicts arise because the term operations is used to describe different services. The provider may mean server maintenance, while the customer expects updates and troubleshooting in the content management system.

The agreement should clearly distinguish between the operating environment, the application and the content. Server operations typically include capacity, the operating system, the network and basic security updates. Application maintenance may include the content management system, extensions, themes, integrations and compatibility testing. Content work is usually a separate service.

Updates should first be tested in a separate test environment when the consequences of errors are significant. It must be possible to check key functions before the change is moved to production, and there should be a rollback plan.

Choose the operating environment based on risk and workflow

Shared hosting may be sufficient for a simple website with steady and moderate traffic. A more isolated or scalable environment may be appropriate when the website experiences major traffic peaks, has complex integrations, e-commerce functionality or stricter access-control requirements.

The choice is not only about capacity. Also consider how easily the environment can be replicated for testing, how changes are moved between environments, which logs are available and how much the provider actually manages. A technically flexible solution can become demanding if the business itself has to handle all updates, alerts and errors.

Ask for a specific explanation of what happens when the load increases. Does the solution scale automatically, must additional capacity be ordered, or will the website simply become slower? The answer should be understandable to the person responsible for operations, not just the server technician.

Agree on how errors are handled

When something goes wrong, the business needs a known point of contact. It should be clear how critical incidents are reported outside normal working hours, which severity levels are used and when the customer can expect an initial response.

An initial response is not the same as a completed solution. The agreement should therefore distinguish between confirmation, troubleshooting having begun, a temporary measure and a permanent fix. For serious incidents, the customer should receive brief status updates along the way, even when the cause is not yet known.

After a major error, a brief review of the cause, impact and actions is useful. The aim is not to assign blame, but to prevent recurrence and improve procedures, monitoring or the technical setup.

A practical checklist before signing the agreement

1. Map critical functions: Describe what customers must be able to do on the website.
2. Define the measurements: Clarify how availability, response time and functions are monitored.
3. Assign responsibility: Distinguish between hosting, server operations, application maintenance and content.
4. Check the backups: Ask for procedures for storage, access and tested restoration.
5. Describe the incident process: Agree on points of contact, severity levels, response times and status updates.
6. Plan changes: Establish how updates are tested, approved and rolled back.
7. Review needs regularly: Update the operational requirements when the website gains new features or greater business value.

Professional web operations are not defined by the greatest number of technical terms. They are defined by clear responsibility, relevant measurements and procedures that work when something deviates from normal. A good operations agreement makes expectations concrete before a problem occurs.