Disagreement is a useful observation. It means the two attempts differ in some way: hostname, request, credentials, network, time or policy. Identify that difference before deciding which result is wrong.
A 403 can be reachable and unusable
WebsiteDown currently treats a final HTTP response below 500 as reachable. A 403 therefore contributes to an Up verdict, even though the request was denied. This answers a narrow host-reachability question. It does not mean that a customer can sign in or that an automated client is allowed access.
To reproduce the distinction on a public site you support, compare the response to HEAD with a limited GET:
curl --head --location --max-redirs 5 --max-time 20 'https://example.com/'
curl --location --max-redirs 5 --max-time 20 --range 0-0 \
--dump-header - --output /dev/null 'https://example.com/'These are examples of diagnostic requests, not a claim that example.com returns 403. A server can ignore the range request. If HEAD is rejected but GET works, a monitor using only HEAD may report a different outcome from a browser. WebsiteDown retries with GET after HEAD returns 403 or 405.
A 403 can come from an origin or a security layer. For sites using Cloudflare, its 403 troubleshooting documentation explains several possible sources. Check the actual response and your provider logs; do not assume that every 403 is a bot challenge.
A timeout does not name the cause
A timed-out request did not complete within the probe’s budget. The target may be unavailable, the network path may fail, or automated requests may be filtered. A functioning control URL shows that the probe can reach that control, not that the route to your target is healthy.
WebsiteDown keeps repeated majority timeouts as an unconfirmed Mixed result. Its “likely filtered” label is also an interpretation, not proof of a firewall rule. A target-specific connection or TLS failure can produce similar signals. Compare the browser error, certificate check and provider logs before adding an allow rule.
Two clicks may still be one observation
Look at each region’s checkedAt value in the downloaded JSON. Regional responses can be cached. If the timestamp is unchanged, the response is not a new observation from that region, even if the top-level result was assembled later. Do not describe that as an independently repeated failure.
For a second observation, allow the documented cache window to pass and compare timestamps again. The configured shared cache is 30 seconds with a 60-second stale-while-revalidate window. The methodology explains why retries and cached results require care.
Agreement is different from coverage
A result from one working probe says less about geographical scope than eight working probes. Missing probe endpoints do not count as target failures, and the current verdict uses a majority of usable results. Check both the agreement count and the number of configured probes that returned evidence.
The configured locations share one hosting provider. Their requests do not sample every residential ISP, mobile carrier, DNS resolver or browser. If the complaints come from a particular network, a successful datacenter probe does not settle that complaint.
Use a monitor that matches the failed action
If your users rely on a particular API, monitor a safe endpoint with the expected response. If they need a rendered browser flow, use a controlled browser test with an appropriate test account. Avoid using a chargeable or destructive transaction as a general health check. For an incident involving login, a successful public marketing homepage is weak evidence.
Define an alert in terms of what it measures: target, method, expected status or content, retry interval, locations and duration. Test it with a failure you control. Then compare alerts with independently observed user impact. This yields evidence about your own setup; a generic quorum recommendation cannot prove that your monitor will catch every outage.
Illustrative comparison, not an incident report
Suppose a user’s dashboard returns 502, while the root page returns 200 in all eight configured locations. Both observations can be correct. The checker has not requested the dashboard. The next step is to capture the failing dashboard request and correlate it with application telemetry. Repeating the root-page check does not test that hypothesis.
Keep the conclusion as narrow as the evidence
Instead of: “The service works for everyone.”
Record: “The origin returned HTTP 200 in 8 available probes at [UTC].
The signed-in dashboard still returned 502 on [network] at [UTC].”
Instead of: “The provider is globally down.”
Record: “6 probes timed out; 2 probe results were unavailable.
Browser behavior and provider incident status are still unconfirmed.”That wording preserves the disagreement for the next investigator. Use the escalation template to attach the hostname, actual failed action and original measurement.