Integration
Jira bug reporting, with the whole report in the ticket
BugBundler captures a bug in one click — annotated screenshot, console output, network activity, DOM snapshot and environment — and files it into your own Jira as an issue, with the complete report attached. No Atlassian Marketplace app, and no report stored on our side.
- No Marketplace app to install
- Reporters need no Atlassian account
- Jira Cloud, Data Center and Service Management
Two ways to get a report into Jira
A finished BugBundler report can reach Jira by either route, and teams commonly use both — the integration for day-to-day tickets, the file for anything going outside the company.
- Send to Jira. An owner or admin connects the Jira site once from the Admin Panel. After that, any member of the company can file a captured report as a Jira issue from the capture panel, with the annotated screenshot and the full HTML report attached to it. Reporters need no Atlassian account of their own.
- Export and attach it yourself. The report is an ordinary HTML file. Drag it onto an issue the way you would attach anything else. This route touches no server at all, works with no network connection, and works on Jira instances that nothing outside your network can reach.
Setting up the Jira integration
This is a one-time job for an owner or an admin, done in the Admin Panel under Jira Integration. Nobody else has to configure anything.
- Create an Atlassian API token for the account that should own the issues BugBundler files, and enter it with the Jira site URL and the account email. The token is stored server-side and is never readable by the extension or by other members of the company.
- Press Test connection. It confirms that the site URL, email and token actually work and names the connected account, so a typo surfaces immediately rather than on the first real report.
- Add a destination for each Jira project that should receive reports: the project key, the issue type, and the URL patterns that project covers.
- Optionally restrict a destination to named users, so a Jira project only receives reports from the people who should be filing into it.
- Paste a URL into Check where a URL would go to see which destination it resolves to, before anyone files a real report against it.
One destination per project, routed by URL
A tester working across several sites should not have to remember which Jira project each one belongs to. Each destination carries the URL patterns it covers, and a report picks its destination from the URL it was captured on. The send button names the project key the report is going into, so the target is visible before the click rather than buried in a picker.
When the automatic choice is wrong, a dropdown on the send button overrides it, and that choice is remembered for that site. If Jira has not been connected yet, the button is disabled with an explanation: admins and owners are pointed at Jira Integration in the Admin Panel, and everyone else is told what is missing and who can fix it, rather than being sent to a page they cannot open.
What lands on the issue
Instead of a description field with a pasted stack trace, the issue carries the evidence:
- The annotated screenshot, attached to the issue — the failure marked up the way the tester saw it.
- The complete BugBundler report as an HTML attachment: console messages grouped by level with timestamps and source, network requests with method, status code, resource type, headers and bodies, the DOM snapshot of the rendered page, Core Web Vitals (LCP, CLS, TTFB), and browser, OS, viewport and user agent. It opens in any browser, with no viewer app and no account.
- A description naming the reporter, the captured URL, the environment and the capture timestamp, plus any custom field values your workspace collects.
- Jira's own Reporter field set to the person who filed it, where their account can be matched with confidence.
How this differs from a hosted tool's Jira integration
The right-hand column describes the pattern common to hosted capture tools rather than any one product. Check the current documentation of whichever tool you are comparing.
Where the data goes when you press send
Worth being exact about, because it is the thing procurement will ask. Capture, annotation and export happen entirely in the browser, and a report you download or attach yourself never touches our infrastructure.
When a reporter presses Send to Jira, that one request carries the screenshot, the compressed HTML report, the title and description, the captured URL, the environment string, the timestamp and any custom field values to a Cloud Function in europe-north1 (Finland), which creates the issue in your Jira site and attaches the files to it. The payload is held in memory for the duration of that request and discarded: it is not written to our database, our file storage or our logs, and nothing is retained afterwards.
Sending is per report and opt-in. It is not automatic, not a background process, and not on by default — it requires an admin to have connected Jira first, and then a deliberate click per report. Your Jira provider is your own processor under your own agreement with them, not a sub-processor of ours. See privacy, the DPA and the GDPR and EU data residency guide.
Password and payment fields are masked automatically, keys
matching patterns such as token,
secret, session and
api_key are replaced with a mask, and browser storage
is excluded from capture by default — see
privacy-first bug reporting
for the redaction controls. Those rules apply before the report is
built, so they apply on both routes into Jira.
Fitting your Jira configuration
Most teams have a bug screen that asks reporters to type environment details by hand — browser, OS, console output — and gets them inconsistently. Those fields can be replaced with the attached report, leaving the fields that genuinely need human judgement: expected behaviour, actual behaviour, and business impact.
Where your workflow needs structured metadata inside the report itself, workspace-level templates and custom fields — dropdown or free text — can mirror your Jira fields so the two stay aligned without double entry. Issue types are resolved by their untranslated name rather than a localized label, so a Jira site running in Swedish or German picks the right type, and an explicit issue type can be set per destination where the automatic match is not what you want.
Data Center, Service Management and restricted networks
A report attached to a Jira issue inherits that project's permissions and retention rules, so it lives inside the system your organization already governs rather than in a separate vendor workspace. That holds on Jira Cloud, Jira Data Center and Jira Service Management alike.
Because capture and export never require outbound connectivity, the export-and-attach route holds on segmented networks and on self-hosted Jira instances that are not reachable from the public internet — see offline bug reporting for enterprise teams. Teams on GitHub can follow the GitHub workflow instead.
Frequently asked questions
Do I need a Jira Marketplace app or plugin?
No. BugBundler talks to Jira's REST API with an API token you create yourself, so there is nothing to install on the Jira side and no Atlassian admin approval to wait for. If you would rather no API connection existed at all, export the report and attach the file to an issue by hand — that route needs nothing but a browser.
Does every reporter need their own Atlassian account?
No. The connection is configured once at company level by an owner or admin, and every member of the company can file reports through it. Where a reporter's account can be matched in Jira with confidence, Jira's own Reporter field is set to them; otherwise the description names them instead.
Can different sites file into different Jira projects?
Yes. Each destination is a Jira project plus the URL patterns it covers, and a report resolves its destination from the URL it was captured on. The reporter can override it before sending, and that override is remembered for that site. You can check how any URL resolves from the Admin Panel before filing a real report.
Where is my Jira API token stored?
Server-side, in a document that denies all client reads and writes and is only ever touched by the backend. The extension cannot read it, and neither can other members of your company. Disconnecting Jira deletes the token and every destination, and requires typing your email address to confirm.
Does BugBundler store my bug reports when I send to Jira?
No. The report passes through a Cloud Function in Finland for the length of one request, purely so the issue and its attachments can be created in your Jira site. It is held in memory and discarded — never written to a database, a file store or a log — and nothing is retained. Reports you download or attach yourself never reach us at all.
Does the issue status sync back to the reporter?
No. Delivery is one way: BugBundler creates the issue and attaches the report, and everything after that happens in Jira. If two-way sync matters to your workflow, a hosted tool such as Marker.io does that and BugBundler does not — the side-by-side comparison is blunt about which trade-off you are making.
Does it work with Jira Data Center?
Yes, provided the site is reachable. On a Data Center instance with no route in from outside your network, use the export-and-attach route instead, which needs no connectivity at all. Jira Cloud and Jira Service Management both work with the integration.
Pricing and where the account data lives
Every plan includes every feature — the Jira integration is not a tier to upgrade into, and neither is 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 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 ticket
File one complete report into your own Jira
Capture a bug in your own environment, send it to a test project, and see what the assignee opens. Or skip the setup entirely, drag the exported file onto an issue, and compare.
All product names, logos, and trademarks are the property of their respective owners. References are for identification purposes only and do not imply endorsement or affiliation. Jira and Atlassian are trademarks of Atlassian Pty Ltd. BugBundler is not affiliated with or endorsed by Atlassian.