Review monitoring whenever a site, server, owner or provider changes. An old monitor can remain green while checking a retired endpoint, and a new production service can operate without any useful alert coverage.
IN THIS ARTICLE
01 Reconcile the active services
- List the business's current public websites, critical service ports and authorised servers. Record each service's owner and environment.
- Compare that list with the Websites and Servers pages. Identify missing coverage, duplicates and retired targets.
- For each retained monitor, confirm its hostname, protocol, content condition, monitoring locations and alert recipients. Review any manual IP override that bypasses current DNS.
- Check certificate tracking, active maintenance windows and paused alerts. Resolve unexplained suppressions.
- For a migrated service, verify the new endpoint and keep a clear transition record. Export required history before removing an obsolete monitor.
- Review public status pages and shared dashboards so their displayed components match the current inventory.
- Set a recurring internal review and add monitoring checks to project handovers, staff departures and cancellation procedures.
02 Example: decide what your business needs to monitor
For a small online shop, a home-page check is useful but incomplete. Visitors may still be unable to use the checkout or contact form. Write down the customer journeys that matter and choose checks that observe them without creating real orders or exposing customer information.
| Service | Useful observation | What it does not prove |
|---|---|---|
| Public website | The intended page responds and contains expected text | Every application feature is working |
| Business email | The relevant mail service or agreed delivery test works | Every destination accepts every message |
| Hosting resources | Disk and resource trends remain within your operating limits | The application code is correct |
Assign an owner to each alert and record what they should do first. A monitor without a response owner creates notifications rather than protection. Keep critical contact details outside the service being monitored so you can still coordinate when it fails.
Ask us to help distinguish a hosting availability problem from an application failure when the evidence is unclear. Include the monitor's location, time, expected response and observed result. Avoid publishing internal hostnames or credentials on a public status page.
Common questions
Should I delete a duplicate immediately?
First compare its target, location and purpose. Two similar names can represent distinct regions or origin-versus-public checks. Remove only the configuration that is genuinely redundant.
Why is the old server still green after migration?
A monitor may use a fixed IP, an old hostname or a page left running on the retired server. Confirm the path customers actually use.
Does renaming a dashboard update every alert?
Check the monitor and contact settings themselves. A display change does not necessarily alter target configuration or responsibility.