HTTP Status Codes for Bug Reports

An HTTP status code describes a response to one request. In a bug report, record the action, request method and safe path, code, time, and what the person saw on the page. Then compare that response with the expected outcome. A 200 response can accompany a failed business outcome, and a 500 response does not identify the failing component by itself.

The classes are a quick first pass: 1xx is informational, 2xx indicates HTTP success, 3xx is redirection, 4xx is a client-error response, and 5xx is a server-error response. “Client error” describes the request/response class, not who is at fault. A redirect is not automatically a bug; 304, for example, supports cache reuse. These meanings follow MDN’s status reference and the HTTP Semantics specification.

These are short meanings, not a diagnosis. The right column tells a reviewer what else to collect for the affected action.

A status 0 shown by some network recordings means no HTTP response code was recorded; it is not a code sent by an HTTP server. Check the request’s surrounding evidence before deciding whether it was cancelled, blocked, or interrupted. The HAR reading guide works through a synthetic status-0 row.

Contrast both with a fictional checkout POST /api/orders returning 500 while the button remains loading. That is a generic error response plus a visible failure. Record the attempt and inspect logs before naming a root cause.

Suppose a fictional form submission returns 429 and includes Retry-After. Record that header, the attempt count, and whether the page told the tester when to try again; MDN’s 429 reference describes the optional header. Do not repeatedly submit just to measure a limit. If the later attempt returns 200 but the form still appears unsent, report both responses and the visible state as separate observations.

For a 401 after a fresh sign-in, keep the role, request path, and new attempt time. The code identifies an authentication response, while the before-and-after comparison helps the team investigate what changed.

This static snippet uses the fictional 401 case. Select and copy it into your own notes, then replace each value with observations from the actual attempt. Keep private URLs, tokens, and personal data out of shared evidence.

Title: Save asks me to sign in after an idle test session
Starting state: Signed in as a test editor, draft open, then idle before saving.
Action: Change the draft title and press Save once.
Expected: The change saves or the page clearly asks me to sign in again.
Actual: A sign-in prompt appears; the draft remains unchanged.
Network observation: POST /api/drafts/42 returned HTTP 401 at 14:32 in this fictional attempt.
Follow-up: A fresh sign-in allowed a later save. Exact session expiry cause is unconfirmed.

To collect network evidence, follow the HAR capture guide and inspect the file with the HAR analyzer. A console excerpt may add context, but it does not replace a response code. Pair the reviewed result with repeatable steps in the bug-report generator; the sample report shows a fuller handoff.

Published October 9, 2026. Updated October 10, 2026. Method: status meanings are condensed from the linked MDN and HTTP Semantics references; the scenarios and snippet are invented teaching examples.