The best WebCheck target is a public endpoint whose result answers a specific operational question. Start with the pages customers depend on, then add checks that reveal a meaningful regression.
Good starting targets
- Homepage: confirms the main public entry point responds.
- Login page: confirms the public authentication entry point is reachable, without submitting credentials.
- Contact or pricing page: confirms important customer-facing content is available.
- Checkout or basket page: confirms the public page loads, without placing an order.
- API health endpoint: confirms a deliberately designed public health response.
- TCP service: checks whether a configured public host and port accept connections.
Label targets clearly
Use labels such as Homepage, Checkout, Public API or Game service so incidents are understandable. Mark a target critical only when its failure should represent an important service problem; the label does not itself change the observed check status.
Add the right check
Use HTTP for reachability and response conditions, content assertions for stable text, DNS for record changes, TLS for HTTPS certificate health and TCP for connection availability. Do not add every check type to every target without a specific reason.
What not to monitor
Do not add private infrastructure, cloud metadata endpoints, destructive URLs or pages that require secrets unless the supported configuration explicitly addresses that use case. WebCheck does not execute a complete browser journey or place orders.