What gets captured

Every report can carry the debugging context you'd otherwise have to ask for — and a short, deliberate list of things we never collect.

While the widget sits on a page it keeps small rolling buffers, and the moment someone sends a report it snapshots them. Nothing is transmitted until a report is actually sent.

Attached to each report

Console output — the last 100 entries across log, info, warn, error, and debug, with timestamps.
Uncaught errors — up to 30 JavaScript errors and unhandled promise rejections, with message, source, and stack trace.
Failed network requests — up to 30 requests that returned 4xx/5xx or failed outright, as method, URL, status, and duration.
User actions — up to 40 breadcrumbs: clicks (the button's label, never what was typed), form submits, and navigation, so you can retrace the steps that led to the bug.
Environment — browser, viewport and screen size, language, timezone, platform, connection type, device memory, page URL, and referrer.

Never captured

These are design decisions, not roadmap gaps — the widget goes on your client's site, and their users' data isn't ours to take:

Request bodies and headers (so no tokens, no payloads).
Anything typed into a form — click breadcrumbs identify the field, not its value.
Cookies or storage contents.
Session replay — there is no always-on recording. Capture starts when the reporter clicks, with the browser's own permission prompt.

Technical context is a Pro feature. On the Free plan, reports carry the recording or screenshot and the reporter's note; the context is discarded at upload rather than stored. See Plans & billing.

Where it shows up

Open any report and the Technical context section renders errors first, then failed requests, the user-action trail, the collapsible console log, and the environment grid. Slack messages include a one-line summary (e.g. 1 console error · 2 failed requests).