How to read failed and slow requests in a bug report

When a visitor reports a problem on your website, one small line of evidence can point you straight at the failing part: a request that failed or took too long. A failed or slow request entry is metadata, not a transcript. It tells you which request went wrong, when it went wrong, and how long it took. It does not tell you why it went wrong. This guide explains how to read each field honestly and turn one entry into a useful source question.

What one request entry contains

A request entry in a bug report should stay small on purpose. Each entry contains:

• The HTTP method, such as GET or POST.
• A path, such as /api/cart, without query values.
• The response status, such as 503, when the browser received one.
• The duration of the request.
• The time the request happened.

That small shape answers the first two questions of any investigation: which request, and when. Everything else is work you do against your own source and logs.

Read the status first

The status code, when present, tells you where the failure became visible.

• A status in the 4xx range suggests the request never reached a working handler on your side: the address was wrong, the resource was missing, or a rule refused the request. A 404 on a path that should exist points at routing or a deployment problem. A 401 or 403 points at an authorization check.
• A status in the 5xx range suggests the request reached your server and the server failed while handling it. A 500 points at the code path behind that route.
• An absent status means the browser never received a response at all. The connection may have dropped, the browser may have stopped the request, or the page may have blocked it.

Treat a status code as a location, not a cause. A 500 tells you the server failed on that route. It does not tell you which line of code failed, and it does not distinguish a broken condition from an unavailable dependency. Pair the status with the path and the visitor action before you open the source.

Slow is not the same as failed

A request can return a clean 200 and still ruin the page for the visitor. A slow entry with a successful status often points to work the handler waits on: a slow query, a distant third-party service, or a response larger than the visitor expected.

One slow entry is a hint. The same slow path appearing in several reports from the same page is a pattern worth checking, and a slow path that appears in reports of an intermittent problem is a good first place to look. For that class of problem, read how to investigate an intermittent website bug.

What the entry cannot tell you

A request entry in a report deliberately contains no query values, no headers, no request body, and no response body. This is a privacy boundary, not a gap. Headers and bodies can carry passwords, account credentials, and private customer records, and a report channel should not collect them.

Do not work around the boundary by asking a visitor to paste a request body or an error payload into a report. The guide to reporting an API error without sharing secrets shows the safer alternative: the method, the path, the status, and what the visitor did just before.

Pair the entry with the other evidence

One request entry is strongest next to the rest of the report:

• The visitor statement says what the person did and what they expected.
• Console errors and warnings say what the page itself complained about, often at the same moment. Learn to read them with how to read a console error as a non-developer.
• A visitor-approved screenshot shows the visible result.

Build a short timeline: the visitor action, then the console message, then the failed or slow request. The order usually tells you which evidence is a symptom and which is the trigger. The overview of what browser evidence helps covers each category and its limits.

Turn one entry into a source question

Map the entry to a concrete question before you search the code:

1. A 404 on a known path: does the routing or build configuration still produce that path?
2. A 5xx on a path: what does the handler behind that route do, and which dependency can fail inside it?
3. A slow entry on a path: what does that handler wait on, and can the wait happen before the first response byte?
4. An absent status: can the page load that resource in a way a browser or extension blocks, such as mixed content or a refused cross-origin call?

Answer the question against the source revision the visitor actually used. A finding that matches yesterday's code proves nothing about today's problem, so pin the deployed commit so reports map to source.

How IssueProbe records requests

The IssueProbe widget records only failed or slow request metadata: the method, a path without query values, the status when available, the duration, and the time. It never records query values, headers, or bodies, and the buffer of recorded items is bounded. A website owner can disable the request category, but no setting can add a value field to it.

During an investigation, this evidence can connect to the source through citations, and the result states a conclusion status of Confirmed, Likely, Possible, or Unknown. A likely or confirmed conclusion needs repository evidence, and a confirmed conclusion also needs direct visitor-browser evidence. An honest result can also say that the cause is unknown.

Read the exact field rules on the widget privacy page, and see how the parts of a result are separated in the example report.