How to Send Console Errors and Network Requests to a Developer

To send a console error to a developer, open the browser's developer tools, reproduce the problem with the Console tab open, copy the red error text including the file and line, and send it with the steps and the page address. For a request that failed, open the Network tab, click the failing request and copy its address, status and response. Take care with anything that includes cookies or tokens, because those should not travel in a message or a public ticket.

Why developers ask for this

A screenshot shows what went wrong on the screen. The console and the network log show why. A page that fails to save usually fails because a request returned an error, or because a script threw an exception. Those two facts are what a developer would look up first, and if you send them, the first round of questions disappears. The wider list of what a report needs is in what developers need in a bug report.

Open the developer tools

In Safari, turn on the developer features first: open Safari's settings, go to Advanced and tick the option to show features for web developers. Every browser also has the tools in its menu under "More tools" or "Develop". Open them before you reproduce the problem. Most of what you need is recorded as it happens, and a page you reload afterwards may not repeat the error.

Copy the console error

1. Open the Console tab. Clear it with the clear button (a circle with a line through it) so old messages do not mix in.
2. Do the steps that cause the problem.
3. Look for lines in red. A typical one reads like Uncaught TypeError: Cannot read properties of undefined (reading 'discount') followed by a file name and a line number, such as cart.js:88.
4. Select the red line and the lines under it (the call stack), and copy them as text. Copy the text rather than photographing it, because developers search for the exact message.

Yellow lines are warnings. They are often noise. Send them only if there is nothing red. Blue lines are plain log messages and rarely matter. If the console is full of red from before your steps, you cleared too late; clear it and try again.

Find the failing request

1. Open the Network tab. Tick Preserve log, so entries survive if the page navigates.
2. Click the filter Fetch/XHR. This hides images and scripts and leaves the requests the page makes to its server.
3. Do the steps that cause the problem.
4. Look for a request with a red status, usually a code in the 400s or 500s, or one marked as failed. A 500 means the server failed; a 401 or 403 means you were not allowed; a 404 means the address does not exist.
5. Click the request. Note its URL, its status and the time. Then open the Payload tab to see what the page sent, and the Response tab to see what came back. The response often contains an error message that names the exact problem.

A request that returns 200 can still be the cause. If the total on a page is wrong, the request that fetched the total may have returned a wrong value with a success status. That is why developers want the response body and not only the status code. Details on that are in why API payloads belong in bug reports.

What to send, and what not to

Right-clicking a request offers Copy as cURL, which gives a developer a command that repeats the request, and the Network tab can export everything as a HAR file. Both are useful, and both can contain things you must not share casually:

• Cookies and session tokens. A copied request or a HAR file usually includes the headers your browser sent, including the cookie that proves you are logged in. Anyone holding it may be able to act as you.
• Authorization headers. The same applies to anything that begins with Bearer or an API key.
• Passwords and card numbers typed into forms appear in the Payload tab of the request.
• Personal data in response bodies, such as names, emails and addresses.

The safe habit is to send the URL, the status and the response text as plain text, remove anything private, and give files such as a HAR directly to the developer, not into a public ticket or a channel with many people. If you must send a cURL command, delete the lines containing the cookie and authorization headers first. If the account you were using is a test account with a throwaway password, change the password afterwards.

A message you can copy

What I did: Added two items to the basket and clicked Pay.
What happened: A red "Something went wrong" banner. No order was created.
Expected: The order confirmation page.

Console error:
Uncaught TypeError: Cannot read properties of undefined (reading 'discount')
    at applyCoupon (cart.js:88)

Failing request:
POST /api/checkout  -> 500
Response: {"error":"coupon_not_found"}

Page: https://staging.example.com/checkout
Browser: Chrome, Windows
Time: today, about 14:20

That message tells a developer where to look in about ten seconds. Compare it to "checkout is broken". The steps part is covered in how to write steps to reproduce.

Or skip all of this

Asking every tester to learn the developer tools is a lot to ask, and most business users will not. The alternative is a tool that records the same facts while they work. With SnagRelay, a tester clicks Report, points at what is wrong and writes what they expected. The console errors with file and line, and the requests with their request and response bodies, are attached to the report, and passwords, tokens, cookies, authorization headers and emails are removed in the browser before it is sent. The person reporting never opens DevTools. The longer version of this argument is in bug reporting without DevTools.

FAQ

How do I copy a console error?

Open the Console tab, reproduce the problem, select the red error and the lines under it, and copy them as text. Include the file name and line number that appear at the end of the line.

What is the difference between the Console and Network tabs?

The Console shows messages and errors from the page's scripts. The Network tab lists every request the page made to a server, with status codes and responses. A failed save usually shows up in one or both.

Is it safe to share a HAR file?

Treat it as sensitive. A HAR file can contain cookies, tokens, form data and response bodies. Share it only with the developer who needs it, never in a public ticket, and change the password of any account whose session it captured if you are unsure.

What if there is no error in the console?

Then the problem may be in a request that succeeded with a wrong answer, or purely visual. Check the Network tab for the response of the request that feeds the part of the page that is wrong, and send a marked-up screenshot as well.

Further Reading

• Bug reporting without DevTools
• Why API payloads belong in bug reports
• How to report a bug to a developer when you are not technical
• SnagRelay for QA and UAT teams