Read the snippet as control flow rather than as a check. `AbortSignal.timeout(10000)` does not produce a status code; at ten seconds it rejects the promise, so `res.status === 200` never evaluates [1]. A slow origin, a dropped route and a firewall that hung up all arrive in the same catch block, and a response landing at 10.1 seconds is indistinguishable from a connection that was refused [2]. The four-state reframe the author proposes, reachable, refused, broken or unknown [7], is therefore a data model change before it is a better assertion. One boolean has room for one of those four outcomes; the other three all render as down [1]. That is the mechanism behind the claim that collapsing four states into two is where most false positives come from [7].
The distinction that pays for itself immediately is 403 against 500. The first says the server is alive and refusing your specific request; the second says something broke [6]. Treat them the same and every portal with a WAF in front of it becomes permanent downtime in your history, which the author says teaches users to ignore the tool inside a week [5].
Asserting on the response body is the next step up, because a React shell rendering "Something went wrong" returns 200, and so, frequently, does a maintenance page [9]. A maintenance page is the rare case of a service telling you the truth in the body and lying in the header. It helps, and it still caps what an external check can claim: you are asserting on a page, not on a payment [3].
The crowd-first conclusion is the part to test before borrowing. The author states it strongly, that for consumer-facing services reports beat synthetic checks rather than supplementing them [12], and weights the tracker accordingly: reports first, server check second, with unreachable-and-unreported rendering as "we could not reach it" [13]. For that to transfer you need arrivals. The floor the author sets is geographic spread rather than raw count, because one report is a person with bad Wi-Fi, and reporting has to be one tap with no login to get the volume at all [16]. A service with a few dozen accounts in one city cannot clear a spread floor [3], which puts you back on page assertions and copy that is honest about what they prove. Fabricating activity is the one shortcut the author calls genuinely fatal [16]. The cold start is brutal, and a crowd tracker with no crowd is a server pinger with extra steps [15].
The last constraint is where the monitor lives. On 18 November 2025 a Cloudflare outage took down X and ChatGPT, and Downdetector went down with them because Downdetector runs on Cloudflare, as does the author's own tracker [17]. Monitoring should not share a failure domain with the things it monitors [18], and that is a hosting decision taken long before anyone writes the check.
