A Green Status Light Isn’t Enough: Monitor Your Website the Way Customers Use It

Category: Hosting and Operations

Uptime is often measured by checking whether the homepage responds. That is useful, but it provides an incomplete picture. The website can be available while the contact form fails, product data is not updated, login stops working or a payment function is unavailable.

Professional web operations should therefore monitor the service the way customers actually use it. This requires more than a green status light for the web server. You need to follow the entire delivery chain, from DNS, CDN and cache to the application, database and external integrations.

Uptime Must Be Linked to a Specific Function

The question “Is the website up?” is too imprecise. A better starting point is to ask which functions must work for the website to do its job.

For a consulting firm, this might mean that service pages load, the contact form accepts enquiries and a confirmation is displayed. For an online store, it could mean product search, stock status, shopping cart and payment. For a membership portal, login and access to protected content may be essential.

Create a short list of business-critical customer journeys. Prioritise them according to the consequences of failure:

• Critical: The failure stops sales, enquiries or access to a paid service.
• Serious: An important function is impaired, but the customer has an alternative route.
• Limited: The failure affects content or functions that can wait until normal working hours.

This prioritisation should guide monitoring, alerting and response times. There is little value in waking someone at night because a rarely used image is missing, while a broken order form remains undetected until the next day.

Monitor Delivery at Multiple Layers

Good monitoring consists of several checks that complement one another. Each layer answers different questions and makes it easier to identify the cause when something goes wrong.

1. External Availability

An external check visits the website from outside and measures whether it responds, how long the response takes and whether the correct content is returned. The check should not only look for a successful status code. An error page can also be returned as an apparently successful response.

The check should therefore look for a specific text element or another expected part of the page. This helps you detect more cases where the server responds but the application delivers incorrect content.

2. Application and Database

A cached homepage can work even if WordPress, the database or another publishing solution has stopped. Monitoring should therefore also test a check that reaches the application itself.

Such a health check can verify, among other things, that the application starts, the database responds and the necessary storage areas are available. It should be fast and limited so that monitoring does not create unnecessary load.

3. Critical Customer Journeys

A synthetic test imitates a user’s actions. It can open a landing page, fill in a controlled test form and verify that the correct confirmation is displayed. In an online store, it can add a test product to the shopping cart and verify that checkout opens without completing a real purchase.

The tests must be designed so that they do not send false enquiries, affect inventory or disrupt reporting. Use dedicated test data and clarify how it should be filtered out of ordinary workflows.

4. External Dependencies

Many websites depend on services outside the operating environment itself. These may include payment, search, maps, video, CRM, newsletters or product data. The website may be technically available while such an integration has stopped working.

Map which external services each critical customer journey requires. Then monitor the outcome of the integration, not just whether an external server responds. For a form, for example, it is more important to verify that the enquiry is registered in the right place than that the integration returns a technical response.

CDNs and Caching Can Both Help and Hide

CDNs and caching reduce load times and the load on the origin server. They can also keep parts of the website available during short-term outages. At the same time, they can hide errors.

If monitoring only visits a cached page, everything may appear normal while the underlying application is down. You therefore need checks of both what customers receive through the CDN and the original operating environment.

Also monitor whether incorrect content is being cached. A temporary error page, old price or outdated product status may remain in the cache longer than intended. The incident procedure should therefore describe when the cache should be cleared, who can do it and how the result is verified afterwards.

Avoid disabling all caching as your first response. This can increase the load on an already strained server. Instead, limit the problem to specific pages, content types or cache layers.

Alerts Should Lead to Action

Too many alerts make it harder to detect the important ones. Monitoring should reduce noise, not produce a continuous stream of technical messages.

A useful alert should tell you:

• Which function is failing.
• Whether the error affects customers or only an internal check.
• When the error started and whether it has recurred.
• Which technical layers are still working.
• Who is responsible for investigating the issue.
• What should be checked first.

Add a short delay or require repeated failures where appropriate. A single slow response does not need to trigger a full incident response. For a critical payment or login function, however, the threshold may be lower.

Create a simple fault matrix

A fault matrix makes it easier to move from symptoms to likely causes. It does not need to be extensive. Start with the most common combinations.

• The front page works, but dynamic pages fail: Check the application, database and cache.
• The website works internally, but not externally: Check DNS, CDN, certificate and network access.
• The pages load, but the form fails: Check validation, email delivery, CRM integration and error logs.
• Only some visitors experience errors: Check geographic CDN nodes, devices, browsers and privacy settings.
• Everything gradually becomes slower: Check resource usage, database queries, queues, storage capacity and external services.

The matrix should be kept together with contact information, access procedures and decision-making authority. When operations fail, it is the wrong time to look for someone who can clear the cache or restart a service.

Backup must be linked to the type of incident

Backup does not resolve every operational failure. A slow integration, incorrect CDN configuration or expired access is rarely fixed by restoring the entire website. An indiscriminate rollback may also overwrite new orders, users or editorial changes.

Therefore, describe what should be restored in different situations. This could be a single file, a database, uploaded content, configuration or the entire environment. Also clarify which data may be lost during a rollback and who can approve it.

Before major maintenance, you should verify that the relevant backup has been completed and is available. After a rollback, the critical customer journeys must be tested, not just the front page.

Maintenance must be visible in monitoring

Updates, database work and infrastructure changes can trigger alerts. Do not address this by disabling all monitoring. Instead, register a defined maintenance window and retain the checks that can reveal unexpected consequences.

After maintenance, the responsible person should check the application, cache, CDN and the most important customer journeys. Continue monitoring for a period afterward as well. Some errors occur only when the cache is rebuilt, traffic increases or a scheduled job starts.

Choose an operating environment based on how well it can be monitored

Capacity and price are important when choosing hosting, but the operating environment must also provide the necessary insight. You should be able to examine resource usage, response times, errors, scheduled jobs and infrastructure changes.

A managed environment may be appropriate when the business wants the provider to handle operational management and platform maintenance. A more flexible environment may be suitable when the solution has special requirements and you have the expertise to manage it. Regardless of the model, the division of responsibilities must be clear.

Clarify who follows up on alerts, who can change the CDN and cache, who maintains the application and who contacts external providers. Monitoring without clear ownership only records that the problem persists.

Start with the three most important checks

You do not need to monitor everything from day one. Start with one external availability check, one check of the application outside the cache and one synthetic test of the most important customer journey.

Then test the alert chain by deliberately causing a harmless error in a controlled environment. Confirm that the right person receives an understandable alert and knows what to do. Repeat the exercise when customer journeys, integrations or responsibilities change.

The goal is not to have as many measurement points as possible. The goal is to detect real problems early, understand where they occur and get the right person to act before the error develops into lost sales or missed inquiries.