🎯 What You Will Learn
Inspect browser console output, request and response details, and diagnose frontend failures that the UI alone cannot explain.
- Filter useful browser console messages
- List and inspect individual HTTP requests
- Read request and response headers and bodies
- Connect network evidence to visible UI failures
Use Console and Network as Two Signals
The browser console shows runtime warnings and errors. Network inspection shows whether data was requested and what the server returned. Together they explain many blank, stale, and partially loaded interfaces.
Reproduce from a Known Page State
Open the page, snapshot it, and reproduce the smallest failing interaction before reading the logs.
"$PWCLI" -s=inspect open https://example.com --headed
"$PWCLI" -s=inspect snapshot
"$PWCLI" -s=inspect click eACTION
"$PWCLI" -s=inspect snapshotInspect Console Messages by Level
Start with warnings or errors to reduce noise, then widen the view when you need application logs.
"$PWCLI" -s=inspect console warning
"$PWCLI" -s=inspect console error
"$PWCLI" -s=inspect consoleList Browser Requests
The requests command returns numbered entries. Look for failed status codes, repeated calls, missing API requests, or unexpected domains.
"$PWCLI" -s=inspect requests[12] GET https://example.com/api/profile 200 [13] POST https://example.com/api/order 422 [14] GET https://cdn.example.com/app.js 200
Inspect One Request in Detail
Use the number from the current request list. Start with the combined request view, then ask for specific headers or bodies when needed.
"$PWCLI" -s=inspect request 13
"$PWCLI" -s=inspect request-headers 13
"$PWCLI" -s=inspect request-body 13Read the Response
Response headers explain content type, caching, and correlation IDs. The response body often contains a validation or authorization message hidden by the UI.
"$PWCLI" -s=inspect response-headers 13
"$PWCLI" -s=inspect response-body 13Protect secrets: Headers and bodies may contain tokens or personal data. Redact sensitive values before copying output into an issue.
Map the Request Back to the UI
Compare the action timestamp, request URL, status code, response message, and visible state. A 422 response needs different work from a click that never sent a request.
| Evidence | Likely direction |
|---|---|
| No request appears | Event handler, disabled control, or overlay |
| 401 or 403 | Authentication, authorization, or expired state |
| 422 | Submitted data does not match the API contract |
| 500 | Server failure; correlate with backend logs |
Capture a Complete Debug Package
Add a screenshot and focused trace after console and network inspection. This gives the next developer visible state plus the sequence that produced it.
"$PWCLI" -s=inspect screenshot
"$PWCLI" -s=inspect tracing-start
# Reproduce once.
"$PWCLI" -s=inspect tracing-stopRecap
- Console and network data explain different layers of a frontend failure.
- Use request indexes from the current request list.
- Inspect both request and response before assigning blame.
- Redact secrets from shared debugging artifacts.
Checkpoint: You have completed the workflow and have a repeatable reference for your next Playwright project.