Information checked: 21 July 2026.
Uptime monitoring checks whether a website or endpoint is reachable, but a 200 response from the home page does not prove that DNS, checkout, forms or customer accounts are working correctly.
In brief: Use uptime as one signal and add transaction checks for the functions that generate business value.
Choose meaningful checks
- Monitor from more than one external location where practical.
- Check HTTPS and certificate validity, not only an IP address.
- Verify expected content as well as status code.
- Add separate checks for critical APIs, forms or booking endpoints.
- Use a maintenance state so planned work is distinguishable from an incident.
Set escalation by impact
| Condition | Suggested severity | Response |
|---|---|---|
| One probe fails briefly | Investigate automatically | Retry from another location |
| Public site unavailable from multiple locations | High | Open incident and check DNS, hosting and recent changes |
| Checkout or booking unavailable | Critical during trading | Activate fallback and notify operations |
| Non-critical page missing | Moderate | Create repair task and check related links |
Measure honestly
Published availability percentages depend on what is measured, how planned maintenance is treated and whether partial failures count. Define the service boundary before promising an uptime figure.
Acceptance check
Simulate a non-production endpoint failure and confirm detection, retries, notification, acknowledgement and recovery message. Keep monitor account access outside the monitored hosting account.
Design checks that resist false alarms
One monitoring location may have a network problem that the website does not. Require confirmation from another location or a second signal before waking an on-call responder, while treating a failed checkout or security warning as higher priority.
Records to keep
- Monitored URLs and expected content.
- Retry and multi-location rules.
- Planned-maintenance process.
- Availability calculation definition.
Owner test: Review one month of alerts and identify which caused action, which were noise and which customer failures were missed.
Monitor dependencies separately
A page may be available while DNS intermittently fails, the certificate approaches expiry or an external booking API is unavailable. Separate checks help identify the responsible layer and avoid unnecessary changes to a healthy application. They also support clearer supplier evidence when raising a support case.
Sources and date checked
This practical guidance was checked against the following primary sources. Date checked: 21 July 2026.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.