Integration

GitHub issue bug reporting workflow

Export BugBundler reports and attach them to GitHub issues for high-context debugging and faster pull request turnaround.

Workflow fit

  • Pairs well with repo-native issue templates.
  • Improves reproduction quality for contributors.
  • Works without cloud recorder services.

The workflow, step by step

  1. Reproduce the problem in the browser and open BugBundler on the affected tab.
  2. Capture a full-page or selected-area screenshot. Console output, network activity, the DOM snapshot, viewport, browser, and OS are collected at the same time.
  3. Annotate the screenshot to point at the actual defect, then set a title, description, and severity.
  4. Export the report as a single HTML file and attach it to the GitHub issue, alongside whatever your issue template already asks for.

GitHub accepts the exported file as a normal issue attachment, so nothing about your repository configuration has to change and no app needs to be granted access to your organization.

One exported HTML file at the centre of arrows pointing to Slack, Microsoft Teams, email, Jira and Azure DevOps
The export is an ordinary file, so a GitHub issue is one destination among many. The same artifact drops into a pull request comment, a Slack thread or an email unchanged.

What the person picking up the issue gets

The gap between "the page broke" and a fixable issue is usually evidence. Opening the attached file gives a maintainer the report in tabs rather than a wall of pasted text:

  • The annotated screenshot, plus the exact URL and the time of capture.
  • Console messages separated by level — errors, warnings, info, and logs — with timestamps and source.
  • Network requests with method, status code, resource type, headers, and request and response bodies, so a failing call is visible without asking the reporter to re-run anything.
  • Core Web Vitals for the captured page — LCP, CLS, and TTFB — which is often enough to separate a perceived hang from a real regression.
  • Browser, OS, viewport size, and user agent, which resolves most "works on my machine" exchanges immediately.

Pairing with issue templates

If your repository already uses issue forms, the highest-value change is usually to stop asking contributors to transcribe environment details by hand. Replace the browser, OS, and console fields with a single instruction to attach a BugBundler report, and keep the fields that need human judgement — expected behaviour, actual behaviour, and impact. Reporters type less, and what they submit is machine-collected rather than remembered.

Notes for open-source and external reporting

Attachments on a public issue are public. Because a report can include console output, network bodies, and a DOM snapshot, treat it the way you would treat a log dump. Password and payment fields are masked automatically, keys matching patterns like token, secret, session, and api_key are replaced with a mask, and browser storage is excluded from capture by default — but for a public repository it is worth setting per-domain capture rules and reviewing the report before attaching it. See privacy-first bug reporting for the redaction controls.

For internal repositories on restricted networks, the same workflow applies without change, since capture and export never require outbound connectivity — see offline bug reporting for enterprise teams. Teams working in Jira instead can follow the Jira workflow.

Pricing and where the data lives

Every plan includes every feature — there is no tier to upgrade into for console capture, redaction, or EU hosting. Seat pricing runs $27 to $29 per seat per month with a five-seat minimum, and every plan starts with a 30-day free trial, no credit card required. Account data, not report content, is the only thing that reaches our servers, and that is hosted entirely in the EU: Cloud Functions in Finland, database in Stockholm, Sweden. See pricing and the GDPR and EU data residency guide for the full detail.

Try it on your next issue

Attach a complete report to a real GitHub issue

Capture one bug in your own environment, drag the file into the issue, and see what the person picking it up opens. No app to authorise, no repository access to grant.