Skip to content
HostTracker Docs

Why is it down: down, unreachable, degraded or challenged

View as Markdown

When a monitor reports down, HostTracker has confirmed the failure from more than one location (see down detection). What it cannot know is why. External monitoring sees the symptom; a few different real-world situations produce it. The error codename, the locations that confirmed it and the snapshot usually tell you which one you are looking at.

Common shapes of “down”

Section titled “Common shapes of “down””
Shape What is happening Typical codenames
Actually down The server is not answering, or answers with a server error. ConnectionRefused, ConnectTimeout, ConnectionReset, Timeout, Http 500-Http 504, WebServerDown (521), OriginUnreachable (523), OriginTimeout (524), CdnError (520)
Unreachable The checker could not reach the server at all: name resolution or routing failed between the checking location and you. Your site may be fine elsewhere. DnsHostNotFound, DnsResolveFailed, NameNotResolved, DomainNotFound, DnsTimeout, HostUnreachable, NetworkUnreachable, NoPublicDns
Degraded or wrong The server answered, but too slowly, incompletely, or with the wrong content. Timeout, KeywordsMissing, AssertFailed, ContentTooLarge, RedirectLoop, Http 404
Challenged A bot-protection or WAF service showed the checker a CAPTCHA or block page instead of your content. A person in a browser gets through. Http 403, Http 429, Http 503 from a CDN, often with a challenge page in the snapshot
TLS problem The connection failed on the certificate or handshake. TlsCertRejected, TlsHandshakeFailed, CertExpired, CertNameMismatch, SslHandshakeFailed (525), InvalidSslCert (526)

Every codename is explained in the error codes reference.

How to tell which one it is

Section titled “How to tell which one it is”
  1. Read the codename and message. In the app, open the outage from the monitor’s statistics page; the panel shows the Errors and an Error breakdown. Through the API, cause.codename on the incident.
  2. Look at which locations confirmed it. GET /monitor/incident/{id}?expand=recheck lists the location that detected it, the locations that confirmed it (with their errors) and any that still saw it up. Failures from one region only point to a network or regional DNS problem; failures everywhere point to your server.
  3. Open the snapshot. For a Website or API monitor the snapshot shows the response the checker got: a challenge page, a maintenance page, an error page, or your page without the expected keyword.
  4. Check it again now. Run an instant check from several locations (in the app, via POST /check, or the MCP tool run_instant_check) to see whether it is still failing and where.
  5. Compare with what you see. If your browser loads the page but checkers get Http 403 or a CAPTCHA, it is a challenge.

What to do

Section titled “What to do”
  • Challenged: allow-list HostTracker’s checking addresses in your WAF, firewall or bot-protection settings. The current list is public and needs no token: GET https://api2.host-tracker.com/agent/ip.
  • Unreachable from some places: check your DNS (all name servers answering, no stale records) and any geo-blocking. Consider the monitor’s locations.
  • Degraded: raise the monitor’s timeout only if slow responses are acceptable to your users; otherwise treat it as a real performance problem. Check that the keyword or assertion still matches your page.
  • Actually down: it is a real outage. Add a note to the incident with the cause once you know it, and post an update on your status page if you have one.

A downtime that looks longer than what you saw may be a resolution effect - see Short outages recorded as long downtime.

Section titled “Related”