What the widget records

What travels with a report

Every feedback submission carries:

• Page URL — the address of the page the feedback was written on
• Browser and operating system, derived from the user agent string
• Screen and viewport size, and the browser language
• Console logs — the last 50 entries
• Failed requests — up to 15 entries
• The selected element, if the reporter pointed at something specific
• A screenshot and any files the reporter chose to attach

All of it is visible to you in the dashboard on the feedback detail view. Nothing is hidden from the account that receives the report.

Console logs

The widget keeps a rolling buffer of the last 50 console.log, console.warn, and console.error calls made on the page and attaches it to the report. Entries are recorded as your site produced them, so whatever your own code chooses to log is what appears.

Worth knowing: if your application logs request payloads, user records, or tokens to the console, those end up in the buffer. That is your logging decision, not something the widget adds. If it matters for your site, keep sensitive values out of the console.

Failed requests

Network failures never reach the console. When a request returns a 500 or is blocked, the browser writes that straight into its developer tools, and no JavaScript on the page can see it as a log line. Since a failed request is the most common cause of “I clicked the button and nothing happened”, the widget watches for them directly and records them alongside the console entries, tagged network.

An entry looks like this:

POST https://yoursite.com/api/checkout failed: 500 Internal Server Error

That is the whole entry. It records:

• the HTTP method
• the origin and path of the request, with no query string
• the status code, or the reason it never completed, such as a network error or a timeout

Only failures are recorded. Successful requests are ignored entirely. Repeated identical failures are collapsed into one entry, so a retrying request cannot flood the report.

Why query strings are stripped

This is deliberate, and it is the one place where we knowingly give up diagnostic detail.

Query strings routinely carry secrets. A password reset that fails would put its reset token in the report. A call to ?access_token=… would put a live credential in it. A lookup like ?email=jane@example.com would put one of your users' personal data into a bug report they never knew was being written.

None of that belongs in our database. So the widget removes the query string before the entry is created, on the user's device, before anything is sent. The values never leave the browser and we never receive them. Path segments that look like email addresses are replaced with [redacted] for the same reason, and very long segments are truncated.

The practical consequence: you can see which endpoint failed and how it failed, but not the parameters of that one call. In our experience the endpoint and status are what you need to reproduce a bug, and the parameters are what you would have to explain to a data protection officer.

What is never recorded

• Query strings on failed requests, as described above
• Request and response bodies — the widget reads neither
• HTTP headers, cookies, and authorization tokens from your site's requests
• Successful requests — no general traffic log is built
• Keystrokes, form contents, or session replay — the widget does not record the session
• The widget's own calls to VibeVaults, filtered out so our traffic never clutters your reports

Your obligations as the site owner

The widget only appears for people you have invited, and it collects this context at the moment someone chooses to send you feedback. Even so, under the GDPR you are the data controller for your users' data and VibeVaults is your processor. If you operate in the EU, your own privacy notice should mention that submitting feedback shares page context and console output with a third-party provider.

Our side of that arrangement, including retention and deletion, is described in the Privacy Policy.