Business systems / Explainer
Your website is online. Can the customer still do the job?
Imagine a booking website whose homepage still opens while the date selector has stopped working. A monitor that only requests the homepage may continue to report a successful response.
I want the monitoring plan to name the customer task we care about. We can then decide which parts to check and what someone should do when the result changes.
Write down what each check establishes
A successful server response is a useful observation. It does not, by itself, show that a visitor can operate every control or that a later step has saved the record the business needs.
For a fictional service page, a read-only check could load the page and look for the expected service information. That is a more specific result than simply receiving a response, but it still has a defined limit: it has not sent an enquiry.
Keep that limit in the monitoring record. The owner should be able to see what is checked and which parts of the journey need a different test.
Choose checks around the work the site supports
Start with the pages and actions the business relies on. A service page, a search result and an appointment selector may each depend on a different part of the system.
AWS CloudWatch Synthetics is one example of a service that runs scheduled endpoint and browser checks. Its documentation describes following routes through an application, checking content and recording timing. The useful question for an owner is which of those checks fits the task.
| Planning item | What to agree |
|---|---|
| Task | The page or controlled journey that matters |
| Expected result | The content, choice or record the check should establish |
| Scope | Which parts are read-only and which need isolated test controls |
| Alert owner | Who receives a failure and investigates it |
| Review | When to update the check after a website change |
Source: AWS: synthetic monitoring
Control tests that have side effects
A check that creates an order, booking or message needs an agreed test design. Use authorised test accounts and fictional data, isolate outgoing activity and decide how test records will be identified and cleaned up.
Keep access to the test results limited too. Browser captures and logs can include private information. AWS’s security guidance discusses protecting canary results, narrowing permissions and keeping sensitive details out of scripts and recorded requests.
Agree which checks are suitable for the live website and which belong in an isolated test setup. Repeatedly creating real customer activity is a poor monitoring plan.
Give the alert a person and a next step
Name the person who receives a failure and what they should inspect first. Include planned maintenance and the route for reporting a problem that a customer sees before a monitor does.
When the website changes, review the expected result as well as the page itself. A check looking for an old service name may need updating; a failed task may need fixing. The alert needs enough context for someone to tell the difference.
Bring the customer task you most want to keep working when we discuss hosting and support. We can use it to agree useful checks and clear responsibilities.
Sources
Checked on 23 October 2026.
- AWS: synthetic monitoring
Scheduled endpoint/browser checks can inspect application routes, content and latency; each configured check has a particular scope.
- AWS: security considerations for synthetic checks
Controlled destinations, scoped permissions, protected results and attention to sensitive information in scripts and captured material.