Why should I monitor my server from outside its own network?
A check running only on the server can miss failures in public DNS, routing, firewalls or upstream connectivity. External checks observe a path closer to a customer’s experience. Use them alongside internal metrics so the team can distinguish an application failure from a network-path problem.
Before you start
- An approved public endpoint and knowledge of the intended customer regions.
Instructions
1. Choose representative probe locations
Use locations and networks relevant to your users, with more than one independent path when the availability requirement warrants it. Avoid assuming that one remote probe represents every customer. Account for private services that should be checked through an authorised private path instead of exposed publicly.
2. Test the right response safely
Validate DNS, connection, TLS and the expected application outcome with bounded timeouts. Use a safe endpoint and a frequency proportionate to the service. Do not make automated checks purchase items, send messages or repeatedly trigger expensive processing.
3. Correlate before changing the server
Compare failing regions, address families and endpoints with internal metrics and application logs. Separate a provider-wide issue, a regional route problem and a single monitor fault. Monitor the checker’s own freshness and route alerts through an independent channel where feasible.
Check the result
- A controlled external-access failure is detected while internal-only success remains distinguishable.
- Probes produce the expected result without unwanted business actions or significant load.
Troubleshooting
- Only one monitoring location reports failure
- Compare another independent location, DNS answers and address-family paths before restarting services. A location-specific route or monitoring fault may explain the discrepancy.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.