Skip to main content
Every Jam automatically captures the technical data engineers expect from the browser’s own developer tools: console logs, network data, and environment details. No setup or configuration required. You can capture additional metadata with Custom logs.

​
Console logs

Every Jam records the console output from the captured page, with a severity filter to show only errors, warnings, or specific log levels.
Console tab in a Jam showing captured logs with severity filters

​
Network requests

Jam captures request and response details, including bodies, for all XHR and fetch requests on the page. Each request includes complete timing breakdowns (DNS lookup, connection time, and response duration), matching the data engineers expect from Chrome DevTools.

​
GraphQL

GraphQL returns a 200 status code even when the response body contains errors, and it typically routes every operation through a single /graphql endpoint. That normally means combing through each request to find the failure. Jam handles both problems automatically:
  • Error detection: Jam flags GraphQL responses that contain errors in the response body, even though they return HTTP 200.
  • Operation names: Jam detects and shows the GraphQL operation name directly in the request list, so you can identify specific queries and mutations without clicking into each request.

​
When bodies are missing

A few edge cases prevent Jam from capturing the request or response body:
  • Timing: the request happened before Jam was initialized on the page. This depends on when your application’s scripts load compared to Jam’s.
  • CORS: the browser performed a preflighted OPTIONS check that did not pass, so the request body was never sent.
  • Static assets: images, scripts, and other non-programmatic assets (anything that is not XHR, fetch, or WebSockets) are not captured.

​
Secrets and redaction

Network request inspector showing JAM_DOES_NOT_SAVE_SECRETS in place of access-control-allow header values
We understand sensitive information can be present in network requests, which is why Jam scans all network requests for any possible sensitive information including tokens, cookies and PII. We filter out these fields on the client side so they never reach Jam’s servers. We remove any potentially sensitive fields from request headers, and (if in JSON), request bodies. This is done prior to Jam creation, so the Jam data you see on the page (with the JAM_DOES_NOT_SAVE_SECRETS strings as the values of these headers) has already been filtered before leaving your laptop. It does not reach Jam’s servers. In the resulting Jam, you will see JAM_DOES_NOT_SAVE_SECRETS in place of any possible secret information. We prefer to over-filter than under-filter and are taking the route of being overly cautious, so sometimes you will see information filtered out that probably should not have been. Help us improve our filtering accuracy by sending your feedback to hello@jam.dev.

​
Binary payloads

When a request or response body contains binary content (Protocol Buffers, WebSocket binary frames, MessagePack, gRPC payloads, or other non-text formats), Jam displays a placeholder instead of the raw data:
The placeholder tells you the data is binary and how large the payload is in bytes. Use the content length to verify whether the expected amount of data is being sent and received. To inspect the actual payload, use your browser’s native DevTools alongside Jam to decode the data with format-specific tools.

​
FAQs

For Jams captured with the browser extension, DevTools data is captured automatically with no setup required. Jams submitted through a Recording Link capture screen recordings only by default. To also collect console logs and network requests, connect your domain and install Jam’s scripts on your site.