External Uptime Monitoring
How CTO2B checks your production endpoints from outside your environment, what to allowlist, and how to send your critical URLs.
CTO2B checks your production endpoints from outside your environment, the way a customer would reach them, so an outage is noticed even when everything inside the cluster looks healthy. This page explains what the checks do, what you may need to allow through, and how to tell us which URLs matter most.
What is checked
- Production endpoints only. The checks target your public-facing production URLs.
- Roughly every 60 seconds, each endpoint receives one read-only
GETrequest. - Nothing sensitive is sent. No authentication, no payload and no session state — the check behaves like an anonymous visitor loading the page.
- All checks come from one fixed source IP.
When a check fails, CTO2B is alerted and investigates. This runs alongside the in-cluster platform alerting described in Observability; you do not need to set anything up.
If you filter bot or unrecognised traffic
If your production endpoints block bots, unknown user agents or traffic from unrecognised IPs, the checks can be blocked and show your site as down when it is not. Raise a request and the CTO2B team will provide the source IP for you to allowlist. See also IP Allowlisting for Applications and Databases.
The same applies to endpoints restricted to an IP allowlist at the ingress: they cannot be checked until the monitoring IP is added. See Ingress Troubleshooting if you are unsure how your ingress is restricted.
Tell us your critical URLs
By default, a check confirms that the endpoint answers with a success status. That catches most outages, but not a page that loads with an error message or a blank screen. You can make the check stricter by sending us your 1–3 most critical URLs, each with an expected keyword:
| For each URL, send | Example |
|---|---|
| The URL | https://app.example.com/login |
| A word that only appears when the page really loaded | Sign In |
The keyword proves the right application answered, not just a web server or an error page. Raise a request in your dedicated Slack channel with the list; the same route works for changing or removing a URL later.
API hosts often return
404or a redirect at the bare root (/), which a simple check reads as down. If you have a health endpoint such as/healthor/ready, include it in your list with the word it returns (for exampleOK), so the check tests the right path.
What is not covered
- Non-production environments are not checked.
- Non-HTTP services, such as SFTP, are not covered by these checks.
- Internal-only endpoints, reachable only through a VPN or private network, cannot be checked from outside.
Related articles
- Observability — logs, metrics and in-cluster alerting
- Ingress, Custom Domains and TLS
- Ingress Troubleshooting
- SLA Policy
- Getting Help
Updated 26 days ago