Skip to content
Toado Docs

Bug report widget

The Toado bug report widget adds a configurable reporting button to a product you control. Customers can report from the page where a problem happened without a Toado account or browser extension. Toado creates a ticket in the project you choose and attaches the available screenshot and browser evidence.

The widget is included with Toado Team. External reporters do not consume paid seats. Each project has its own key, appearance, capture settings, allowed sites, and destination board.

Before you start

  • A Toado Team workspace and destination project.
  • Owner access.
  • Permission to add a script to the target site.
  • A safe test page or staging environment.

If the site has a strict Content Security Policy (CSP), plan to merge the sources generated by Toado into its existing directives. A tag manager works only when the site’s CSP and loading rules permit it.

Choose where to start

Company Settings → Bug report widget shows every project and its status: Not set up, Off, On, not detected, or Live. Use it to review or begin setup across several products.

Project Settings → Widget opens the full Widget Studio for one project, with Install, Appearance, Capture, and Security sections.

Company Settings overview listing project widget status and setup actions.

Install your first widget

  1. Open the project that should receive reports.
  2. Go to Project Settings → Widget.
  3. In Install, turn on Widget is on and select Save changes.
  4. Copy the complete snippet under Add this to your site.
  5. Paste it before the closing </body> tag on every page where the launcher should appear.
  6. Deploy, then open a deployed page containing the snippet.
  7. Return to Install and check installation detection.
  8. Review any detected origin, add the correct origin to the allowed sites, and save.
  9. Reload the site and submit a test report.
  10. Confirm the ticket appears in the selected project with the expected screenshot and evidence.

Widget Install section showing the enabled state, detected snippet, allowed Toado site origin, and live preview.

Copy the script exactly as Toado displays it. The loader address and key are generated for the current environment. Do not reuse another project’s snippet. This nonfunctional example shows only its shape:

<!-- Copy the real value from Project Settings → Widget. -->
<script src="TOADO_WIDGET_LOADER" data-toado-key="YOUR_PROJECT_WIDGET_KEY" async></script>

What reporters see

A reporter opens the launcher, describes the problem, supplies configured contact information, answers custom questions, and submits. The reporter does not gain access to the Toado project. The configured confirmation appears after submission.

Bug report dialog with description, optional email, Send report, and Open in Toado actions.

After a report is accepted, the dialog shows its reference for follow-up. Reports submitted in the current browser session also appear under Your reports this session, so the reporter can see what they already sent without gaining access to the project.

A completed report form with one earlier report listed under Your reports this session.

Successful submission confirmation with a follow-up reference.

The reporter dialog listing two reports submitted during the current session.

The resulting ready ticket appears on the destination board. Use External reports to find widget and public-report-link submissions.

What the team receives

Depending on capture level, a report can include:

  • Description, optional reporter identity, and custom answers.
  • A DOM-rendered screenshot with widget UI removed and form-field contents masked.
  • Page address, browser, operating system, viewport, and screen context.
  • Console history, JavaScript errors, and passive network timing in Standard capture.
  • HTTP status codes and redacted request details in Deep capture.
  • A source badge identifying Widget, Report link, or Team snippet provenance.

A resulting Toado ticket with identifying reporter metadata blurred, the captured screenshot on the left, and ticket details and debugging context on the right.

Screenshots can be partial for cross-origin iframes, video, WebGL, protected content, or some canvas implementations. See Widget capture.

Test before broad rollout

  1. Install on staging or an internal route.
  2. Test mouse, touch, keyboard, and the smallest supported mobile width.
  3. Submit after producing a known harmless console error.
  4. Confirm the screenshot excludes the widget and masks form fields.
  5. Inspect Console, Errors, and Network evidence.
  6. Test login, checkout, bot protection, and sensitive flows—especially with Deep capture.
  7. Confirm required fields and the success message.
  8. Expand to production only after these checks pass.

Where to next