Publish the human half
Put the three visitor-facing questions in your help center and your issue template. Keep it short enough to read in one glance.
Bug Report Template: Copy-Paste Format, Form, and Examples
A bug report is only useful if an engineer can reproduce it. This page gives you a template you can paste into your tracker today, the format variants for Jira, GitHub, Word, and Sheets, worked examples of a good and a bad report, and the fields you should stop asking humans to fill in by hand.
Free forever: 3 sites, 150 reports/month, no credit card.
Pro free for your first month. No credit card required.
For QA, support, and engineering teams
Anyone standardising how bugs get reported, whether that is an internal QA process, a help center article for customers, or an issue template in your repository.
Templates ask humans for machine data
Almost every bug report template in circulation asks the reporter to type their browser version, operating system build, console errors, and network failures. Non-technical reporters cannot supply those fields, so they leave them blank. Technical reporters can, but resent doing by hand what the browser already knows. Either way the template that looked thorough returns half empty.
Split the human half from the machine half
Ask the reporter for expected behaviour, actual behaviour, and steps if they know them. That is genuinely all a human can contribute reliably. Capture the environment, console output, failed requests, JS errors, and interaction trail automatically at submit time, and the same template stops coming back empty.
Fields a Bug Report Needs
Grouped by who should be filling them in. The second group should never be typed by a person.
-
Title and summary
One sentence naming what broke and where. "Checkout submit does nothing on Safari" beats "site broken".
-
Expected versus actual
Two short lines. This pair is what turns a complaint into something a developer can verify against.
-
Steps to reproduce
Numbered and specific. If the reporter cannot recall them, an automatic interaction trail fills the gap.
-
Environment and evidence
URL, browser, viewport, console output, failed requests. Capture these rather than requesting them.
-
Severity and area
Blocks revenue, blocks a workflow, or cosmetic. Plus the owning area so triage can route it without reading twice.
-
Reporter context
Account ID, plan, and app version. Pull these from metadata so you know whose problem this is.
Putting the Template to Work
A template in a wiki gets ignored. A template attached to a button gets used.
Automate the machine half
Let the widget attach URL, browser, console lines, failed requests, JS errors, and the repro trail on submit.
Triage from one inbox
Tag severity and area, then push to Linear or Jira with the same debug bundle attached to the issue.
Format Variants and Worked Examples
The same template adapted to where you actually keep bugs, plus a side-by-side showing why specificity matters.
Where to put it
- GitHub: save it as .github/ISSUE_TEMPLATE/bug_report.md so the fields prefill on every new issue
- Jira: create a Bug issue type with Expected, Actual, and Steps as custom fields rather than one description blob
- Linear: use a template on the Bug label, and post the debug bundle into the issue body through a webhook
- Word or Google Docs: keep the headings as-is and hand it to non-technical reporters as a fillable page
- Sheets or Excel: one column per heading, one row per bug, which suits small QA passes better than a document
A weak report
- Title: "Checkout broken"
- Body: "I tried to pay and it did not work. Please fix."
- What is missing: which browser, which step, what the page did, whether an error appeared, and whether it is reproducible
- Cost: two or three round trips before anyone can even attempt to reproduce it
The same bug, reported well
- Title: "Checkout Pay button does nothing on Safari 18 with a saved card"
- Expected: clicking Pay charges the card and shows the receipt page
- Actual: the button depresses, nothing happens, and the page stays on the payment step
- Steps: 1. Sign in with a saved card. 2. Add any item. 3. Open checkout. 4. Click Pay.
- Attached automatically: a 402 response from /api/charge, an uncaught TypeError in checkout.js, and the click trail leading to the button
Copy-Paste Bug Report Template
Paste this into your issue tracker, help center, or engineering runbook. The first block is what a person fills in. The second is what should arrive on its own.
Bug report template
## Summary
One sentence: what broke, and where.
## Reported by
- Name or account ID:
- Date:
## Expected result
What you expected to happen.
## Actual result
What happened instead.
## Steps to reproduce
1.
2.
3.
## Environment (capture automatically, do not ask)
- Page URL:
- Browser and version:
- Viewport:
- Console errors:
- Failed network requests:
- Uncaught JS errors:
- Interaction trail:
## Triage
- Severity: blocks revenue | blocks workflow | cosmetic
- Area: billing | auth | onboarding | integrations
- Owner:
- Status: open | in review | doneEverything under Environment is captured by FeedBlox at submit time on every plan, including Free. Leave those lines in the template as a checklist, or delete them once the widget is filling them for you.
Install in Minutes
One async script tag before the closing body tag. See the full install guide or the free widget page for Webflow, WordPress, Shopify, and Next.js steps.
Embed snippet
<link rel="preconnect" href="https://feedblox.net" crossorigin />
<script src="https://feedblox.net/widget.js" async
data-site-id="YOUR_SITE_ID"
data-token="YOUR_EMBED_TOKEN"
data-position="middle-right"
data-offset-bottom="16"
data-offset-side="16"></script>Bug Report Template FAQ
Quick answers for teams evaluating FeedBlox for this use case. Read the full FAQ for plans, privacy, and integrations.
What should a bug report template include?
A summary line, expected result, actual result, steps to reproduce, environment details, and a triage block covering severity and owner. The first four come from the person reporting. The environment section should be captured automatically rather than typed.
How long should a bug report form be?
Two to four fields for whoever is reporting. Longer forms look thorough and return empty, because the extra fields are almost always asking for technical data the reporter cannot see. Length in the template is fine as long as most of it fills itself in.
What is the difference between a bug report and a bug report template?
The report is a single filed issue. The template is the reusable structure that makes every report contain the same fields, so triage does not have to guess what is missing.
Do I need a Word or Excel bug report template?
Only if your reporters live in those tools. A document template is fine for a one-off QA pass or for non-technical stakeholders. For anything ongoing, an issue template in your tracker or a widget on the product itself will stay current where a document will not.
Which fields can be captured automatically?
Page URL, browser and version, viewport, recent console log and error lines, failed fetch and XHR calls with status codes, uncaught JS errors with source hints, your own app metadata, and a summary of the last interactions before submission.
Can I use this template with FeedBlox?
Yes, and that is the intended pairing. Publish the human-facing questions in your help center, run the widget on your site, and the environment section arrives filled in on every report without the reporter opening DevTools.
Stop asking users to fill in the environment section
New accounts get Pro free for your first month: unlimited reports, screenshots, recordings, webhooks, and collaborators. No credit card. After the trial, Free forever: 3 sites, 150 reports/month, no credit card.
Start Free
No credit card required