Troubleshooting

Start from the symptom you're seeing. Each section below explains the most likely cause and points you to the tool or guide that resolves it.

The endpoint reports down, but the site works for you

Your browser and the probe are in different places, on different networks, with different caches. A site can be fully healthy from your desk and still be unreachable from the region that checks it.

• Run a diagnostic chain from the endpoint's detail panel. It executes DNS, path, port, TLS, and response checks from the probe's location and shows you exactly which step is failing.
• If the endpoint checks from more than one location, compare them on the response-time chart. One location reporting down while another is healthy usually indicates a regional cause, such as a localized outage in a single data center, or a network or DNS problem specific to that region, rather than a problem with your service itself.
• If the failures are HTTP 403s or challenge pages on a site that loads normally in a browser, bot management may be blocking the probe; see the next section.

Bot management is blocking the probe

CDN and WAF bot protection (Cloudflare Bot Management, Akamai Bot Manager, AWS WAF Bot Control) scores requests and challenges ones that look automated. A monitoring probe looks automated by design, so these products can block a legitimate check even when real users are unaffected.

Canary9 recognizes the common block patterns and records those checks as Blocked (violet in your charts) instead of failed: they don't fire outage alerts and don't count against uptime. While checks are blocked, however, you have no real signal from that location, so we recommend restoring it.

The fix is an allowlist rule for the probe's User-Agent in your bot-management product. Allowlisting Canary9 probes has step-by-step instructions for Cloudflare, Akamai, and AWS WAF, and explains why probes get blocked in the first place.

Reviewing an incident after the fact

When a web, browser, TCP, or ping check goes down, Canary9 automatically captures a diagnostic chain at the moment of failure and attaches it to the alert event, so you don't need to be at the dashboard when an incident happens. In Alerts → Event log, expand the down event's Diagnostics captured at failure to see the DNS, path, port, and TLS/response state exactly as it was at the moment of failure, even if the endpoint has since recovered. See the event log.

Gaps in the chart, or "Missing monitoring data" alerts

The status bars and charts distinguish three kinds of "no data", and they mean different things:

• Grey: time from before the endpoint existed. No action is needed.
• Amber: the monitor was deliberately paused. Resume it from the toggle on the endpoint row.
• Red-highlighted gap: checks should have run but nothing was recorded. This counts against uptime, and the managed Missing monitoring data policy raises an alert when an active endpoint goes silent for about three check intervals. The alert resolves itself when results resume. See default policies.

The endpoint is up, but slow

• The phase timing chart under the latency chart breaks each HTTP check into DNS, connect, TLS, and TTFB bands, so you can see which phase is consuming the time. For multi-location endpoints, use the region tabs above it to view one location at a time.
• The Statistics section (next to the Diagnostics button) shows p50/p95/p99 latency and where failures concentrate by phase.
• For a live view, run a diagnostic chain: its network path stage shows per-hop latency, so you can tell whether the slowdown is near your infrastructure or further out in the network. What common results mean covers how to read it.

The site returns 200 but the check fails

If the check has a content check configured, a correct status code isn't enough: the response body must also match (or avoid) the configured keyword or pattern. When it fails, the endpoint's detail view shows a captured excerpt of what actually came back, so you can compare it against your rule. A maintenance banner, an error page served with a 200, or a changed page layout are the most common causes. See Verify response content.

Certificate warnings

HTTPS endpoints show the observed certificate's expiry and a days-remaining countdown in the detail view, and the managed TLS certificate expires soon policy warns when it enters the 14-day window (critical once expired). A diagnostic chain's TLS handshake stage shows the full certificate card (subject, issuer, days left) as the probe sees it, which catches the case where a load balancer or CDN is serving a different certificate than the one you renewed at the origin.

Still need help?