Monitor what must actually work: Build operations around critical user journeys
A website can respond to monitoring while still failing customers. Here’s how to connect uptime, caching, CDN, backups and maintenance to the functions the business depends on.
A green server status does not necessarily mean that the website is working. The homepage may be available from cache while the contact form is failing. The online store may load quickly but stop at checkout. A logged-in service may respond normally for existing users while new users are unable to create an account.
Professional operations should therefore not only measure whether the server is up. They must verify that the most important user journeys can actually be completed. This requires the business to define what is critical, monitor multiple layers and agree on who should respond when something goes wrong.
Start with the impact, not the infrastructure
It is easy to start with technical measurements such as CPU usage, memory, disk space and response time. Such data is useful, but says little about the impact a failure has on the business.
Instead, start by listing the actions the website must support. For a corporate website, this might include submitting a contact form, finding contact information and downloading product documentation. For an online store, it might include searching for a product, adding it to the shopping cart and completing payment. For a membership portal, logging in and accessing the right content may be critical.
Then select a limited number of critical user journeys. Each journey should have a clear definition of what counts as successful. “The online store works” is too vague. “A test user can add an available product to the shopping cart and reach the payment step” can be verified.
A simple prioritization
- Critical: The failure stops sales, inquiries, logins or delivery of a core service.
- Important: The failure affects many users, but a temporary workaround is available.
- Routine: The failure is visible or inconvenient, but does not stop a core action.
This prioritization should guide monitoring, alerts and the expected response time. If everything is marked as critical, the on-call operator will quickly be overwhelmed by alerts that do not require immediate action.
Monitor multiple layers of the same user journey
Good monitoring consists of several complementary checks. A simple uptime check is still useful, but it must not stand alone.
1. Check that the service responds
An external check should regularly retrieve selected pages from a location outside the operating environment. This can reveal an unavailable server, DNS resolution errors, expired certificates and network problems.
The check should not only look for a successful status code. It should also verify that the page contains the expected content and that the response time remains within an agreed threshold. Otherwise, an error message may be delivered with a technically successful response.
2. Test the action itself
For critical functions, monitoring should simulate a simple user journey. This could involve opening a form, entering test data and verifying that the submission is registered. In an online store, a test could add a product to the shopping cart and confirm that checkout opens with the correct contents.
The tests must be designed so they do not create fake customer inquiries, affect inventory or make real payments. Use dedicated test products, test accounts and clearly marked data wherever possible.
3. Monitor the infrastructure
Capacity and error-rate measurements provide necessary context when a user journey fails. High database load, a full disk or a backlog of background jobs can explain why a function has become slow or unstable.
Set alerts for trends over time, not just absolute thresholds. Disk usage, for example, may grow steadily because of logs or backups. It is better to intervene before storage is full than to wait for an outage.
Prevent caching and CDNs from hiding the failure
Caching and CDNs reduce load times and relieve the server. At the same time, they can make monitoring misleading. A cached copy of the homepage may be delivered quickly even if the underlying application or database is not working.
Therefore, monitor both the public delivery and the origin behind the cache. The public check shows what the user receives. A separate check against the application shows whether the system can still generate content and process dynamic requests.
It is particularly important to distinguish between static and dynamic components:
- Product pages and articles can often be delivered from cache.
- Shopping carts, checkout, logins and personalized pages normally need to be handled dynamically.
- Forms can be displayed from cache, while the submission itself depends on the application, database and email or integration services.
Monitoring should also verify that the cache can be cleared and rebuilt without errors. After a publication or technical change, old and new resources may otherwise be mixed, causing users to receive broken pages even though the server is available.
Make alerts actionable
An alert that only says “the website is down” sends the recipient searching unnecessarily. A good alert should state which check failed, when the failure started, whether it has been confirmed from multiple locations and which user journey is affected.
The alert should also point to an agreed first action. For a contact form failure, this might be checking registered submissions and setting up an alternative contact channel. For a checkout failure, it might involve investigating the payment integration and temporarily pausing paid advertising.
Create a simple alerting plan covering the following points:
- Who receives the alert during and outside business hours?
- Who determines the severity?
- Who can make changes to the operating environment?
- Who informs management, customer service or the marketing department?
- When should a vendor or integration partner be brought in?
It should be possible to answer these questions without searching through old emails or relying on one particular employee.
Connect backups to monitoring
Backups are an important part of operations, but a notification that a job has completed is not enough. Monitoring should verify that new backups are actually being created, that their size is reasonable, and that the copies are stored separately from the production environment.
A suddenly very small backup may indicate that files or database data are missing. An unexpectedly large backup may be caused by growing logs, temporary files or old backups being included again.
The required frequency must be determined by how much data the business can afford to lose. A content site that changes weekly has different needs from an online store with continuous orders. The database, files and any external data must be assessed as a whole. Restoring the database is of little use if essential product images, documents or configurations are missing.
Use maintenance as preventive operations
Maintenance should be an established process, not a cleanup carried out after something has already stopped working. The plan should include updates, log reviews, storage cleanup, certificate reviews, alert testing and checks of critical user journeys.
After every major change, the most important tests should be run again. This applies not only to changes to the website. New CDN rules, adjusted caching, server software updates or changes to the security setup can affect functionality without being visible in the administration interface.
Also plan regular reviews of your monitoring. Testing an old form has little value if the business now uses a new ordering solution. Monitoring must evolve alongside the website.
Choose an operating environment based on what you can manage
The choice between shared hosting, managed operations, a virtual server, a dedicated environment or a more complex cloud solution is not just about performance. It is also about the division of responsibilities and operational capacity.
A flexible environment offers little value if no one is responsible for the operating system, security updates, database, logs and incident handling. Similarly, a standardized platform may be a good choice when the business wants clear responsibilities, predictable maintenance and fewer components to manage itself.
Ask for specific answers before choosing a solution:
- Which parts are monitored around the clock?
- Who responds to application errors, not just server errors?
- How are traffic peaks and capacity increases handled?
- Where are backups stored, and how long are they retained?
- Who maintains the cache, CDN, database and server software?
- How is the business notified of incidents that affect users?
The most important distinction is between what the vendor can technically deliver and what is actually included in ongoing operations. Make sure responsibilities are clarified in writing.
Create a simple operations map
You do not need an extensive governance system to get started. Create an operations map with the most important user journeys in the left column and their dependencies on the right: web server, database, CDN, cache, payment solution, email, search or other integrations.
Define one or more checks for each critical journey. Then specify who receives the alert, what the first action is and how quickly the situation should be assessed. Review the map after major changes and at least whenever responsibilities, vendors or core functions change.
The result is an operation that looks beyond whether the server responds. It monitors what the website is designed to do, detects errors closer to the user and gives those responsible a better basis for taking action before the problem becomes prolonged.
