Widget data sheet
What the DebugGo widget reads, stores, sends and keeps, by install mode.
Last updated: 2 November 2026. Describes widget 1.1.0.
The short version
The widget loads no third-party scripts, sets no cookies for ordinary visitors, builds no identifier for them, and sends nothing to DebugGo until a person presses Send. In the default team-only install, an ordinary visitor never contacts DebugGo at all.
What happens on page load
There are three ways to install the widget. The dashboard install snippet picks the first two for you based on the project's visibility setting; self-hosting is a manual option described on the consent and self-hosting page.
| Team-only (inline loader, default) | Everyone (plain script tag) | Self-hosted | |
|---|---|---|---|
| Who it is for | Your own team reviewing the live site through a review link. Visitors never see it. | Every visitor can open a feedback bubble. | Either of the above, served from your own domain. |
| Requests to DebugGo for an ordinary visitor | None. No script download, no API call, nothing. | One: the download of widget.js from debuggo.dev (about 19 KB). Like any script download, the request carries the visitor's IP address, user agent and the page URL as the referrer, and lands in our hosting provider's request logs. | None. The script comes from your origin. |
| DebugGo code that runs for an ordinary visitor | About twenty lines of inline JavaScript on your page. It checks whether the URL contains debuggo_review and whether one browser storage key for your project exists. If neither, it stops. | The full widget: it draws the floating button and waits. | The full widget, from your copy. |
| Browser storage read | One localStorage key, debuggo:review:<apiKey> (or the cookie debuggo_review_<apiKey> if you chose cookie storage). Needed to recognise a teammate who already opened a review link. | The same one key. | The same one key. |
| Browser storage written | Nothing, until a review link is opened. | Nothing, until a review link is opened. | Nothing, until a review link is opened. |
| Console and failed-request capture | Never for ordinary visitors. For a teammate, capture starts once their review link is validated and the review layer appears (see capture modes below). | Starts the first time the visitor opens the widget or starts an element capture (data-capture="on-open", the default). Only data-capture="always" starts it at page load; choose that only if you disclose it. | Follows whichever mode you install. |
| Visible UI | None for visitors. The review dock appears only after a valid review link. | A floating feedback button. | Follows whichever mode you install. |
| Data sent to DebugGo | Nothing until a reviewer presses Send. | Nothing until the visitor presses Send. | Nothing until someone presses Send. |
When a teammate opens a review link
A review link is ?debuggo_review=<token> on your own site's URL. Opening it is the request for the service, and from that point the browser does the following:
- The token is removed from the visible URL and kept in browser storage for 30 days so the session survives page changes.
widget.jsis downloaded from debuggo.dev (or your own origin if self-hosted), thenreview.js.capture.jsloads only when the reviewer starts an element capture.- The token is validated against DebugGo on every page load. A disabled or rotated link stops working at the next load and the stored token is removed.
- Console and failed-request capture starts at this point for the reviewer, so their bug reports can include diagnostics.
- The reviewer sees a one-line notice explaining what is kept in the browser and what a bug report includes, with a link to this page.
- The review API returns the project's existing review comments so the reviewer sees them pinned on the page. It refreshes every 30 seconds while the tab is visible.
Browser storage
Nothing in this table exists for a visitor who only browses. Entries are created after a person opens a review link (or, on sites using the unified experience for everyone, when a visitor names themselves or posts an on-page comment), and each has a lifetime.
| Where | Key | Set when | Lifetime | What it holds and why | Basis |
|---|---|---|---|---|---|
| localStorage | debuggo:review:<apiKey> | A review link is opened | 30 days from the last time the link was opened. Removed on Finish review or End team session, when the link is disabled, or when it expires. | The review access token and its expiry, so the session continues across pages and visits. | Strictly necessary for the review service the link-holder asked for. |
| localStorage | debuggo:reviewer:<apiKey> | The reviewer first types a name or sends a comment (in a review session or the unified experience). Opening the page or the bubble and closing it writes nothing. | 30 days, renewed on each later comment or name change, and on each later visit while a review link is active. Removed together with the token on Finish review or End team session. | A random reviewer id, the display name the reviewer typed, and the ids of their own comments, so only they can edit or delete those comments. | Strictly necessary. |
cookie (opt-in, data-review-storage="cookie") | debuggo_review_<apiKey> | A review link is opened | 30 days. SameSite=Lax, Secure, Path=/, host-only. Removed on Finish review or End team session, or when the link is disabled. | The same access token as the localStorage entry, for sites that prefer a cookie. Replaces the localStorage token; it is not set as well. | Strictly necessary. |
| memory only | (none) | The feedback form opens, a review link is validated, or an element capture starts (default); or page load with data-capture="always" | Until the page unloads. Never written to disk. | The last 100 console messages and the last 20 failed requests, held so they can be attached to a bug report. | Sent only when the reporter leaves “Include technical details” checked. |
There are no other cookies and no other storage. The widget does not fingerprint the browser, does not create an identifier for ordinary visitors, does not share identifiers across sites, and loads no third-party scripts, fonts or pixels. The reviewer id above is per project and exists only for people who opened a review link.
What a report contains
A report is sent once, when the person presses Send. Nothing is sent before that, and nothing is sent in the background afterwards. Under the “Include technical details” checkbox, a “What's included?” disclosure lists the exact counts, browser string and page that will go with the report.
| Field | Included when | Limits and notes |
|---|---|---|
| Message | Always | What the person typed. |
| Email address | Only if the person types one | Optional field. Never read from the page or the browser. |
| Page | Always | Origin and path only. The query string and hash are stripped before sending, because they often carry tokens, email addresses and tracking ids. |
| Browser | Bug reports, when “Include technical details” is left checked | A short browser name and version plus the operating system family (for example “Chrome 130 on macOS”). The raw user-agent string is never sent. Plain feedback carries no browser description at all. |
| Viewport | Always | Width and height in pixels. |
| Timestamp | Always | When the report was sent. |
| Console messages | Bug reports, when “Include technical details” is left checked | The last 100 messages, each cut to 1,000 characters, captured from the moment described above. Redacted before sending (see below). |
| Failed requests | Bug reports, when “Include technical details” is left checked | The last 20 requests that failed: method, origin and path, status code and duration. Never headers, cookies, request or response bodies, or query strings. |
| Element snippets | When the reporter selects elements on the page | Up to 5. Each holds the element’s outer HTML (at most 10 KB), its CSS path and, on React sites, the component name stack. Redacted before sending. |
| Screenshot | When the reporter attaches one | One image, at most 5 MB, PNG, JPEG or WebP. Attached by file picker, drag-and-drop or paste; the widget never captures the screen itself. |
| Review comment extras | Review sessions only | The reviewer’s display name, the page URL with tracking and identity query parameters removed, and the element anchor (selector, a short text excerpt, position and a small HTML snippet) that pins the comment. |
Capture modes and switches
| Attribute | Values | Effect |
|---|---|---|
data-mode | all (default) or review-only | review-only hides the widget from everyone without a review token: no button, no capture, no requests. |
data-capture | on-open (default) or always | When console and failed-request capture starts. on-open begins when the feedback form opens, a review link is validated or an element capture starts, so it misses errors from before that moment; always captures from page load for every visitor and must be disclosed. |
data-capture-console | false | Never capture console messages. |
data-capture-network | false | Never capture failed requests. |
data-review-storage | cookie | Keep the review token in a cookie instead of localStorage. |
data-auto-init | false | Do nothing until your code calls new DebugGoWidget(...), for consent-gated boots. |
data-app-origin | https://debuggo.dev | Where the review API lives, for self-hosted copies of the script. |
Redaction
Console messages, failed-request paths, element snippets (markup, text and attribute values) and the text and markup of a review comment's anchor pass through a redactor in the browser before they are sent, and again on the server before they are stored, so a modified client cannot skip it. The person's own message, email field and reviewer name are never altered. The following are replaced with [redacted]:
- email addresses
- JSON Web Tokens and other bearer tokens, and Authorization header values
- values following password, token, secret, key, auth, session or signature names, in text, query strings and JSON
- 13 to 19 digit sequences that pass the card-number checksum
- long hexadecimal and base64 strings, which are usually keys, hashes or session ids
- UUIDs inside request paths, which usually identify a record or a person
Redaction is pattern-based
It cannot recognise every kind of personal data your application might write to its own console, such as a name in a log line. If your app logs personal data, turn console capture off with
data-capture-console="false" or keep the default on-open capture and tell your users what a bug report includes.Where the data goes and who can see it
| Who or what | Sees |
|---|---|
| DebugGo storage (Supabase) | Every field above, in a Postgres database and in private storage buckets. Screenshots and review attachments are never public; the dashboard fetches them through signed URLs that expire after one minute, the agent API through ones that expire after ten. |
| Members of your DebugGo organization | Everything, in the dashboard. |
| Your agents and scripts, through a project secret key | Everything the dashboard shows, through the agent API and the CLI. |
| Anyone holding a review link for the project | The project’s review comments: message, reviewer display name, page, anchor, replies, status and a linked GitHub issue number. They do not see email addresses, console messages or failed requests. You can disable a link at any time in the dashboard. |
| GitHub (only if you connected a repository) | For reports turned into issues (automatically for bug reports, or manually from the dashboard): the message, the reporter’s email if they gave one, page path, browser string, viewport, console messages, failed requests and element snippets, written into the issue body after redaction. Screenshots are not embedded; the issue carries a link to the report in the dashboard instead. |
| Resend (only if you configured digest addresses) | An hourly digest email with the new messages, reviewer names and page paths, sent to the addresses you entered. |
| Hosting providers’ request logs (Vercel, Supabase) | The IP address and user agent of each request, for the providers’ own log retention period. DebugGo does not store IP addresses in its database. |
The full list of vendors is on the sub-processors page.
Retention and deletion
| Data | Kept for |
|---|---|
| Console messages, failed requests, browser string, bug-report screenshots | The project's diagnostics retention period, 30 days by default, adjustable per project in the dashboard between 7 and 365 days. A daily job removes them once they are older than that. |
| Message, email, page, status, element anchor, element snippets, replies, review attachments | Until a member of your organization deletes the item, or until the project or account is deleted. |
| Review tokens in the browser | 30 days, or until Exit or revocation. |
Any item can be permanently deleted from the dashboard, through the agent API (DELETE /api/v1/issues/:number) or with the CLI (issue delete). Deleting removes the message, its diagnostics, replies and attachments. A linked GitHub issue is not deleted, because GitHub does not allow it; close it there if needed.
If a visitor asks you to delete what they submitted, delete the item; you do not need to contact DebugGo. If they contact DebugGo directly, we forward the request to you and help you complete it within 30 days.
What is never collected
- Keystrokes, mouse movement, scroll position or session recordings
- Form field values, other than the widget's own form
- Request or response headers, bodies or cookies of your application's network calls
- Successful requests. Only failures are kept, and only their method, path, status and duration
- Your visitors' IP addresses, in DebugGo's database
- Browser fingerprints, advertising ids or identifiers shared across sites
- Anything at all, in team-only installs, from a visitor who did not open a review link