Diagnostic chains

A diagnostic chain is a full network diagnostic run from the probe's location, showing you where a request breaks down: DNS, network path, port, TLS handshake, or the response itself. Run one on demand whenever a check is down or slower than it should be.

A diagnostic run answers the question your laptop can't: what does the connection look like from where the check actually runs? A target that resolves and loads fine from your desk can still be unreachable from another region, refuse connections on the monitored port, or serve an expiring certificate.

Open the diagnostics panel

1. Open Endpoints in the sidebar and find the endpoint you're investigating.
2. Expand its row (the chevron on the left) to open the detail panel.
3. Scroll to the bottom of the panel and select Diagnostics, next to Statistics:

Opening the panel starts a run immediately, so there's nothing else to click. A run takes up to ~30 seconds, and the panel shows which location it's running from while you wait. If the endpoint checks from more than one location, the run uses its first listed location.

Reading the diagnostic chain

Results render as a five-stage chain, in the order a real request travels: DNS resolution → Network path → Port status → TLS handshake → Response. Each stage is marked passed, warning, or failed; stages that don't apply to the endpoint's check type (TLS on a plain TCP check, for example) are greyed out. Select any stage to see its detail card:

• DNS resolution: the addresses the target's name resolves to from the probe, so you can confirm the region is even finding the right server.
• Network path: a hop-by-hop route traced toward your service's actual port, drawn as numbered hops with per-hop latency, so the route reflects what your real traffic traverses and you can see where latency piles up.
• Port status: whether the monitored port is open (something is listening), closed (the host actively refused), or filtered (packets silently dropped, which usually means a firewall).
• TLS handshake: the negotiated protocol and cipher, a certificate card with subject, issuer, and days-to-expiry, and a step-by-step connection timeline (DNS → connect → TLS → first byte).
• Response: the HTTP status returned, with its headers. DNS-type checks get a resolution card listing the answers returned instead.

A warning mark means the stage ran but found something worth your attention: a certificate close to expiry, or a network that filters ICMP so the path trace learned little. A failed stage shows the underlying error in plain terms.

What common results mean

• Down, and Port status says closed: the host is reachable but nothing is listening. The service process itself has likely crashed or stopped; the network path is not the cause.
• Down, and Port status says filtered: packets are being dropped before they reach the service. Check firewalls and security rules between the internet and the host, especially after a recent infrastructure change.
• DNS resolution failed: the name doesn't resolve from that probe's region. Check the record, and remember DNS changes propagate unevenly, so one region can fail while another still resolves the old answer.
• TLS handshake warns with few days left: renew the certificate before it expires and the warning becomes an outage.
• Latency jumps at a late hop in the network path: the slowdown is near your infrastructure. A jump at an early hop points at the network between the probe and you instead.
• Response is 4xx or 5xx while the earlier stages pass: the network is fine and the server answered, so the problem is in the application, not the path to it.

Diagnostics captured at failure

You don't have to be at the dashboard when something breaks. When a web, browser, TCP, or ping check goes down, Canary9 automatically runs this same diagnostic from the probe and attaches the result to the alert event. In Alerts → Event log, expand a down event's Diagnostics captured at failure to see the chain exactly as it looked at the moment of failure, even if the endpoint has since recovered. See the event log.

Good to know

• Results are kept for about a minute, so reopening the panel right away shows the same report (marked cached) instead of re-running. Use Run again to force a fresh run.
• Diagnostics work for every check type. Stages a check type doesn't use are shown greyed out rather than hidden, so the chain always has the same shape.
• Runs execute from the probe, never from your browser, so the result is unaffected by your own network, VPN, or DNS cache.