Find the request that actually failed
HTTP status codes describe the outcome of a request. The familiar families cover success, redirection, client errors and server errors. A page can return successful HTML while a required image or API request fails separately. Inspect the individual requests rather than relying only on the visible page.
Start with the exact address, the action the reader took and whether the problem occurs while signed in. Save a timestamp and a screenshot of the symptom. Remove credentials and private information before sharing diagnostic evidence.
Build a small comparison
Compare one failing request with a working one. Are they on the same host? Do they use the same method? Does the failure follow a particular account, region or resource? Change one variable at a time so the comparison remains useful.
A practical incident note can contain four lines: expected result, actual result, smallest reproduction and most recent relevant change. This prevents a discussion from turning into a collection of unrelated guesses. Avoid treating a single response code as proof of the underlying cause.
Verify the reader’s journey
After a fix, repeat the original action from its starting page. Follow redirects, check the final address and inspect any dependent requests. Loading the destination directly may miss the broken link that caused the report.
Retain the reproduction steps with the change record. If the same failure returns, the next person should not have to rediscover what “the page is broken” meant. A useful close-out explains the observed result and the limits of the check, rather than claiming every possible path was tested.
Before you finish
- Exact failing request captured
- Private data removed from evidence
- Original reader journey repeated
Technical reference
MDN: HTTP response status codes