DEV Community

StarkMan
StarkMan

Posted on

What HTTP 200 and 503 Counts Cannot Tell You About an Outage

#cybersecurity #criticalinfrastructure #zoomeye

What HTTP 200 and 503 Counts Cannot Tell You About an Outage

Availability data looks precise until it is asked to explain an incident. A scan can record that a service returned HTTP 200, that another endpoint returned 503, or that no matching response was found. Those observations describe a response at a point in time. They do not explain intent, access, compromise, or the full user experience.

The Bankruptcy Noticing Center outage offers a concrete example. The judiciary reported that BNC websites and the National Creditor Registration Service were unavailable and that notice production and delivery stopped. Later updates reported restoration. External scans collected after restoration can describe the public estate, but they cannot reconstruct the outage from a single status code.

The counts under one scope

The following ZoomEye queries completed successfully on November 2, 2026:

domain="uscourts.gov"                                  1822
domain="uscourts.gov" && service="http"                 878
domain="uscourts.gov" && http.header.status_code="200"  743
domain="uscourts.gov" && http.header.status_code="503"    0
Enter fullscreen mode Exit fullscreen mode

These results overlap. The 743 responses with status 200 are part of the broader parent-domain and HTTP-service populations, not a separate set to add. The zero for 503 does not mean the outage did not happen. It means the selected query did not return matching observations with that status at the collection time.

The timing is important. The outage began in early October, and the public record reported restoration near the end of the month. The query ran on November 2. It is a post-restoration view of related public infrastructure, not a live probe of the failed service during the interruption.

Why a status code is not a security verdict

HTTP 200 means a server returned a successful response. It does not mean the content is trustworthy, the authentication is sound, or the back-end processed the request correctly. An error page, a login screen, a default index, and a real application can all return similar codes.

HTTP 503 means the server was unable to handle the request at that time. It can reflect maintenance, overload, dependency failure, deliberate blocking, or a security control. It is not a diagnosis. A service can also be unavailable without returning 503: DNS may fail, a network path may be blocked, a certificate may be invalid, or a client may receive a timeout.

The BNC incident is a useful reminder that availability has layers. The official notices describe an inability to produce and deliver notices. A website response is one part of that workflow. Polling, certification drop-off, mailing-matrix access, and notice delivery sit behind the web front door.

Build a defensible availability record

Start with the service owner's definition of healthy. For a public portal, a successful login, a successful read, or a completed transaction may be a stronger health signal than a bare 200 response. For a notice-processing system, a health check should include queue depth, polling status, and delivery confirmation.

Use an external scan as a supporting observation, not the system of record. Record the endpoint, response code, body title, redirect target, collection location, and timestamp. Repeat from more than one location when possible. Compare with service logs and user reports before declaring an outage or a recovery.

Treat the query scope as part of the evidence. A parent-domain query returns a broader public view than a query for the named BNC domains. If the narrower query returns one observation and the broader query returns 1,822, the difference reflects the chosen scope and the related population, not the number of services affected by the incident.

Make the limitations explicit

An availability report should distinguish four claims:

  • The service returned a particular HTTP response at a recorded time.
  • The operator reported a service interruption.
  • The operator reported restoration.
  • The root cause and data impact are known.

The BNC public record supports the middle two and parts of the first. It does not support the fourth claim. A status-code count cannot fill that gap.

ZoomEye can help organizations maintain a reproducible public view of court-domain services and compare that view over time. Its practical value is in scope control and evidence preservation. A 743 count for HTTP 200 and a zero for HTTP 503 are useful pieces of a baseline, but they are not a substitute for the BNC's own operational telemetry.

The next check

For a critical public service, pair the external baseline with a transaction-level health check and an incident-contact record. Confirm who can report a failed notice pipeline, who can validate DNS and certificates, and who can distinguish an application outage from a network or dependency failure.

That combination gives responders a better question: which layer changed when the service failed? A status code can help answer it. The code alone cannot carry the conclusion.

References

Top comments (0)