A website can display its homepage while customers are unable to book, sign in or submit a request. Monitoring should reflect the tasks the business depends on, as well as the availability of its infrastructure. Start with the question a staff member would ask during a disruption: which customers are affected, what cannot they do, and who is working on it?
Choose a small set of representative checks
Imagine a Cairns tour operator whose booking page loads normally but fails when selecting a departure. A basic homepage check would miss the problem. Define a safe synthetic journey that exercises the important steps without creating uncontrolled live bookings or charges. A second check might confirm that staff can retrieve today's departure list. Google's SRE monitoring guidance distinguishes observing a system from outside and inspecting internal signals. A modest combination can provide context: the customer journey indicates impact while internal signals help the technical team investigate.
Route alerts to someone who can act
An alert sent to an unmonitored mailbox is a record, not a response plan. Agree who receives each type of alert, during which hours and what they should do first. Use a backup contact for absence. Avoid alerting the whole team for every transient warning; excessive noise makes meaningful signals easier to miss. Define which failures need immediate interruption and which belong in a scheduled review. A customer-facing outage and a slowly growing maintenance concern can both matter without requiring identical escalation.
Show uncertainty and dependencies
If the booking system relies on an external provider, an outage may originate outside the application. Monitoring should identify the affected journey without immediately guessing the cause. Keep an incident note with observed impact, current owner and next update time. If staff use a temporary manual process, explain its limits and record the work for later reconciliation. Recovery should include checking that queued or delayed activity has caught up; a successful page load does not necessarily mean every failed booking notification has been processed.
Practise an actionable alert
In a controlled test, trigger a nonproduction failure and follow the alert from detection to acknowledgement. Ask whether the recipient can identify the affected task without opening several unrelated dashboards. Review:
- Which customer and staff journeys are checked safely.
- Who responds during business hours and outside them.
- What evidence confirms recovery beyond the homepage loading.
- How delayed requests, messages or background jobs are reviewed after an incident.