Guide
Bug Report Examples: From Notes to Issue
Compare fictional bug report examples with generated Markdown: see how steps, expected and actual results, environment, and reviewed evidence help a reviewer.
Read a bug report from observation to handoff
These bug report examples are fictional. Start with the weak note, then compare the added steps, expected result, actual result, environment, and reviewed evidence with the generated Markdown. The builder case concerns a disabled Save button; the agency case concerns a contact form that clears a message. Use whichever failure resembles the report you need to write.
The widget example below uses the product issue formatter; the two later examples use the free bug-report generator. Both show formatted output from the repository’s real functions, with synthetic inputs. No customer report or outcome is represented.
Illustrative ContextCapture widget issue
This synthetic workspace capture uses ContextCapture's issue formatter. Browser details, console lines, and screenshot references are illustrative. No customer report or screenshot is shown.
Create issue button does not respond
- Observation
- On the release-plan workspace, press Create issue.
- Expected
- The new issue form opens.
- Actual
- The button does not open the form.
- Environment
- Synthetic workspace at example.com/workspace · Chrome desktop · 1440 × 900 viewport · medium severity.
- Selected element
- Create issue button · button[data-testid="create-issue"]
- Evidence
- Illustrative screenshot link only. No image was captured for this example.
- Example console error: Cannot read properties of undefined (reading issueDraft).
- Example console warning: Create issue action did not open a form.
Copy the widget-produced GitHub issue bodyOpen the original Markdown to review or copy it.
In this example, the reporter-written description supplies the action, expected result, and observation. The formatter also receives synthetic page URL, browser and viewport context, selected-element details, console lines, and a screenshot URL. The screenshot reference is a placeholder, as the note above says; it is not an image captured for this example.
From a vague report to a usable GitHub issue
The two fictional examples below teach manual reporting. Each starts with a complaint, adds reproducible observations, and ends with the Markdown issue body made by our free bug-report generator. That generator structures notes you enter; it does not capture browser evidence. Replace the example facts with what you actually saw before sharing.
A screenshot or console message is evidence of a state at one moment. A suspected cause is an inference. Keep those separate so the receiving team can investigate without treating a guess as fact.
The generator maps title to the Markdown heading, each line of steps to a numbered action, and the other inputs to expected result, actual result, environment, and evidence sections. An empty field appears as “Not provided”; its completeness checklist shows presence, not accuracy. It does not import another guide’s checklist, collect evidence, or analyze a HAR file.
Builder: a save button stops responding
1. Poor report
“Save is broken. Please fix it.”
The receiver cannot repeat the failure or tell what result was expected.
2. What changed
- A starting page and three actions. A developer can repeat the same attempt. Earlier gap: “Save is broken” names no action.
- The expected enabled button and observed disabled button. The difference identifies the failure without guessing its cause. Earlier gap: No expected or observed state.
- A test browser, viewport, reviewed screenshot, and console observation. The team can compare the visible state with the report. Earlier gap: No environment or evidence.
3. Corrected report and resulting GitHub issue
Issue title: Save button stays disabled after editing a team name. The body below is the generator's Markdown output. Select it to copy into a GitHub issue after reviewing every line.
Observed evidence: The disabled button in the reviewed screenshot is an observation in this fictional test.
Inference to verify: A form-state bug is one possible explanation, not a confirmed root cause.
Agency or QA: a client contact form clears a message
1. Poor report
“Client says the form loses data sometimes.”
The receiver cannot repeat the failure or tell what result was expected.
2. What changed
- Four actions and a stated test session. The receiving team knows which validation path to inspect. Earlier gap: “Sometimes” has no repeatable sequence.
- Expected message retention and the observed need to retype it. The issue explains why the behavior matters. Earlier gap: No visitor impact.
- Staging context, mobile viewport, reviewed screenshot, and repeat count. The team can verify the same state without exposing client details. Earlier gap: No release or reviewed evidence.
3. Corrected report and resulting GitHub issue
Issue title: Contact form clears the message after an email validation error. The body below is the generator's Markdown output. Select it to copy into a GitHub issue after reviewing every line.
Observed evidence: The emptied field after validation and two QA repetitions are observations in this fictional test.
Inference to verify: The report does not claim that Safari caused the problem or that every visitor sees it.
Keep evidence and hypotheses separate
Review a report with missing evidence
Fictional Save-button follow-up
Suppose the generated issue gives clear steps and a disabled Save button, but the browser version is unknown and the screenshot was never captured. Keep the observed behavior in the issue, mark those two details as missing, and ask the reporter to repeat the same steps in a named browser. Do not attach the conceptual illustration above as if it showed this attempt.
If a repeat attempt succeeds, add that outcome and the conditions tested. Keep the earlier failure as an observation, with its attempt count and uncertainty; a single successful retry does not establish that the original report was wrong. Mozilla’s bug-writing guidance recommends precise steps and expected versus actual results so another person can compare attempts.
Make your own report
Before sharing, ask whether another person can repeat the steps from the stated starting state, tell expected from actual, identify the tested environment, and inspect only evidence you have reviewed. Keep missing details unknown and suspected causes separate from observations. Mozilla’s bug-writing guidance also emphasizes precise steps, expected versus actual results, and separating facts from speculation.
Use the free generator to structure facts you collected, or make a reusable GitHub issue template for your team. The reproduction-steps guide helps trim a test sequence; the console guide and screenshot annotator help prepare reviewed evidence. To capture browser context from your site, see the supported widget setup and GitHub workflow.
Updated October 10, 2026. Originally published October 8, 2026.
Examples for your team
Builder example
A builder turns a vague save complaint into steps, the expected button state, the observed state, and reviewed evidence.
Start your 14-day free trialAgency / QA example
A QA tester records a contact-form validation path, the lost message, test environment, and what remains unknown.
Start your 14-day free trial