Browser DevTools

ProcessTier 1 · hear it this weekPhase 1 · Put a page on the internet

The browser's built-in developer window, opened with F12 or right-click then Inspect, that shows the network requests, console messages, and page internals of any website.

Why it exists

When something looks wrong on a screen, the first question is always where: is it the frontend, the request, or the response coming back. Guessing sends the ticket to the wrong team and wastes a day. Browser DevTools exists because the browser already sees all of it, so anyone can open a window on any page and get evidence, the exact call that failed and the exact status it returned, instead of an opinion.

How it actually works

Every modern browser ships a developer panel you can open on any page, yours or anyone else's, with nothing to install. It is several tools in one window. The Network tab lists every request the page makes, each with its method, path, status code, and timing, so you can watch the exact calls behind a screen and see which one failed and how long it took. The Console tab shows errors and log messages the code prints. The Elements tab lets you inspect the live HTML and the styles applied to any element.

For triage, the Network tab is the one that matters most. Reproduce the problem with it open, then read the failing request: a 500 means the server broke, a 401 means you are not logged in, a 404 means the thing was not found, and no request firing at all usually means the frontend never sent it. That single reading routes the bug to the right person before anyone touches code.

It shows real traffic, so it is also how you verify a feature actually works rather than merely looks right, answer a data question straight from the JSON a call returns, find the one slow call dragging a page down, and confirm a tracking event fired when you clicked.

A senior PM walks you through it

A junior PM, stuck

Checkout showed a generic "something went wrong" and my lead said "open the Network tab and tell me the status code before you file the ticket." I opened it, saw a list of requests scroll by, and did not know which line he meant or how to read it.

The Network tab looks like noise until you know it is just a list of the calls the page made, each with four things that matter: method, path, status, and time. One of them is the failure. This is the capture from a broken checkout, six requests, and I will show you how to find the one line that answers his question. Read it with me and you will have the status code he asked for.

Network tab, one broken checkout attempt

Requests, in the order they fired

200 82

200 38

1042 200 31

200 45

200 12

500 610

Click a step to see the lines it points at.

Mistakes I've seen

Filing "checkout is broken" with no status code. The generic screen error tells the engineer nothing; the red row's method, path, and status is the whole ticket.

Reading the first red thing you see. Console warnings are often harmless noise; the Network row with the failing status is the evidence, so go there first.

Confusing a slow call with a failed one. 610ms is slow-ish, but the 500 is why it failed; time and status are different columns answering different questions.

Assuming a 200 row cannot be the problem. A 200 that returns the wrong data is a real bug, but it is a different reading: open the response, do not just trust the green status.

Tell your lead: "Five requests are 200, POST /api/orders came back 500 at 610ms, so it is a server error on checkout, not the button." You read the one red row and routed it. That is the Network-tab triage skill.

Where a PM meets this

A screen shows an error and you open the Network tab: a red 500 means the ticket goes to the backend, a 401 means it is an auth issue, not a broken button.

You want to confirm a new tracking event fires on a click, so you watch the Network tab for the event request instead of waiting on an analyst.

A page feels slow and DevTools shows one call taking two seconds while the rest are instant, which turns a vague complaint into a specific fix.

Hear it in a meeting

"Open the Network tab, reproduce it, and tell me the status code before you file the ticket."

See it in the build

Appears in Phase 1, Put a page on the internet.

Related concepts

API Status codes JSON Bug severity and triage