Reproduce it once yourself
Confirm it happens twice before filing. A report that cannot be repeated by its own author will not survive triage.
What Is a Bug Report?
A bug report is a structured record of software behaving differently from how it is supposed to. It exists so that someone who was not there can reproduce the problem, confirm it is real, and verify it is fixed. This page covers what belongs in one, how to write one, and how a bug report differs from a support ticket or a feature request.
Console logs and network errors on every report, including the free plan. Start with 30 days of Pro free, no credit card. Then Free forever: 3 sites, 150 reports/month.
No credit card required
For anyone filing or receiving bug reports
Written for people new to structured QA, support agents turning customer complaints into engineering work, and teams defining what a bug report should contain before they standardise on a template.
A complaint is not a bug report
"The site is broken" is a complaint. It records that someone was unhappy, which is worth knowing, but it cannot be assigned, reproduced, or verified. The difference between a complaint and a bug report is not tone or length. It is whether a second person can follow it and see the same thing happen.
Reproducibility is the whole test
Everything in a good bug report exists to serve one question: can someone else make this happen again? Expected and actual behaviour define what "this" is. Steps define how to get there. Environment defines where it happens. Console output and network failures explain why. Drop any one and the report gets slower to act on.
Anatomy of a Bug Report
Six parts, in the order a reader needs them.
-
Summary
One sentence naming the broken thing and where it lives. This is what appears in a list of forty issues.
-
Expected behaviour
What should have happened. Without it, a reader has to guess at the intended design.
-
Actual behaviour
What happened instead, described concretely. "Nothing happened" is more useful than "it failed".
-
Steps to reproduce
Numbered actions from a known starting state. The most valuable and most often skipped section.
-
Environment
URL, browser, version, and device. Bugs that appear on one browser and not another live or die here.
-
Evidence
Console errors, failed requests, screenshots. This is what turns a plausible report into a confirmed one.
How to Report a Bug
Three steps, whether you are a tester or a customer.
Write expected and actual first
Those two lines are the report. Everything else is supporting detail that helps someone else get there.
Attach the evidence
Console output and failed requests, ideally captured automatically rather than pasted from DevTools.
What a Bug Report Is Not
Three things regularly filed as bugs that need a different destination, plus how to tell them apart.
Not a bug: a feature request
- "There should be a dark mode" describes something absent, not something broken
- Test: is there a documented or obvious intended behaviour this violates? If not, it is a request
- Where it belongs: your roadmap or feature voting process, not the bug queue
Not a bug: a support question
- "How do I export my data?" is someone who cannot find a working feature
- Test: does the software do the right thing once the person knows where to click?
- Where it belongs: support, though a pile of identical questions is real evidence of a usability problem
Not yet a bug: an unreproducible report
- "It logged me out randomly yesterday" may well be a real bug, but nothing can be done with it as written
- Test: can you or the reporter make it happen a second time?
- What to do: capture session context automatically so the next occurrence arrives with the evidence attached
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.
No credit card required
Embed Snippet
<script src="https://app.feedblox.net/widget.js" async
data-site-id="YOUR_SITE_ID"
data-token="YOUR_EMBED_TOKEN"
data-api-url="https://api.feedblox.net"
data-position="middle-right"
></script>What Is a Bug Report FAQ
What is a bug report?
A bug report is a structured record of software behaving differently from how it is intended to behave. It documents what was expected, what happened instead, how to reproduce it, and the environment it occurred in, so that someone who did not witness the problem can confirm and fix it.
What does a bug report contain?
A summary line, expected behaviour, actual behaviour, numbered steps to reproduce, environment details such as URL and browser, and supporting evidence like console errors or failed network requests. Most teams add severity and an owner for triage.
What is the difference between a bug report and a feature request?
A bug report says the software is not doing what it is meant to do. A feature request says the software does not do something you would like it to do. The test is whether there is an intended behaviour being violated.
How do you write a good bug report?
Reproduce the problem once more to confirm it is repeatable, write the expected and actual results as two plain sentences, add numbered steps from a known starting point, and attach the console output and any failed requests. Specificity in the title saves the most time overall.
Who writes bug reports?
QA testers, developers, support agents translating customer complaints, and end users filing directly through an in-product feedback button. Reports from end users are usually the thinnest, which is the main argument for capturing technical context automatically.
What makes a bug report bad?
Most commonly there are no steps to reproduce, the title is generic, expected and actual behaviour are merged into one vague sentence, or the environment is missing on a bug that only appears in one browser. Each of these adds a round trip before work can start.
Related Pages
Collect bug reports that are reproducible by default
Start with 30 days of Pro free, no credit card. Then Free forever: 3 sites, 150 reports/month.
No credit card required