The former benchmark scores have been withdrawn: there were no published test records to substantiate them. Use the following controlled checks to evaluate HTTP tools for your own workflow.
Test the request the tool actually makes
Start with a public endpoint you control and can inspect in server logs. Record its expected behavior for HEAD and GET. A useful HTTP checker identifies the method, requested URL, returned status and final URL. If you cannot tell which request produced the result, it is difficult to reproduce.
Four fixtures that expose useful differences
- HEAD rejected, GET succeeds: configure HEAD to return 405 and GET to return 200. Record whether the tool reports the first response or a retry.
- A 403 response: verify that the result keeps the code visible even if the tool calls the host reachable.
- A redirect to a 200 page: require the first hop and final status to remain distinguishable.
- A failing subpath: keep the root healthy while a test path returns 503. Check that the tool has not reduced the input to the origin.
These fixtures are a suggested test procedure, not measurements of named vendors. Run them on an isolated test service, not by disrupting an existing public site.
Keep a command-line reference
curl --max-time 20 --silent --show-error --dump-header - \
--output /dev/null 'https://example.com/'This GET request does not follow redirects. Add --location --max-redirs 5 to compare redirect behavior. Preserve the headers and command together; response output without its request options is incomplete evidence.
Where our tools fit
Use the HTTP status checker for HTTP inspection and compare its output with the fixture logs. The main WebsiteDown checker is specifically an origin-reachability tool: it normalizes away paths and counts final responses below 500 as reachable. Its green result is not a claim that every request succeeded.
Evaluate missing details individually: method, redirect chain, access-denied response, timestamp and export. A tool that hides one of those may still be useful for a simple check, but you will need another source for an incident report. Consult the methodology before comparing a host verdict with a status-code test.