A useful bug report shows what failed, how to reproduce it, and what the customer expected. For a customer support team, it also explains the customer impact and links the evidence an engineer needs to investigate.
Below are seven filled bug report examples covering login, layout, performance, API errors, browser differences, and data validation. These are illustrative examples for a fictional application, not incidents reported by Screendesk customers. Replace the sample details with observations from your own investigation. A game-testing example and a guide to what common bug trackers expect follow the six reports.
Annotate the evidence without overstating the finding
A filled bug report becomes easier to review when the evidence has a short index. The index should name what the recording shows and where it appears. It should not turn a visible symptom into an unsupported cause.
| Evidence entry | Useful wording | Wording to avoid |
|---|---|---|
| Starting state | “The saved report is open at 00:05.” | “All report settings are correct” when they have not been checked. |
| Action | “CSV is selected at 00:18.” | “The customer did everything correctly” without the complete prerequisites. |
| Symptom | “The export error appears at 00:24.” | “The database is down” without evidence of that cause. |
| Impact | “No CSV downloaded in this attempt.” | “Nobody can export” when only one session was tested. |
Use this fictional index as a guide to the examples below. Replace the sample times with timestamps from your own evidence. Keep a separate test log if the investigation continues after the initial report.
What should a bug report include?
- Title: the action, affected area, and failure.
- Environment: application version, browser, operating system, and relevant account settings.
- Starting state: the account, data, settings, or save needed before step one.
- Steps to reproduce: a numbered sequence another person can follow.
- Expected and actual results: a separate statement for each.
- Impact and frequency: who is affected, how often it occurs, and whether a workaround exists.
- Evidence: a screenshot or recording, relevant timestamps, and sanitized technical details where available.
- Severity and priority: observed impact and the team’s decision about when to fix it.
Keep observations separate from suspected causes, put one issue in each report, and mark any comparison you did not test as unknown. A polished report is not proof of a particular root cause.
Start with our copyable bug report templates if you need a blank version. A screen recording for customer support can show the sequence that static screenshots miss; the written report should still summarize the result.
1. Login bug report example
A login report should identify the failing step without including passwords, authentication tokens, or customer session cookies.
Title: Login remains on loading screen after valid credentials are submitted Environment: Example application, release 4.2; Chrome on macOS; test account Steps to reproduce: 1. Open the login page in a new browser session. 2. Enter the approved test account credentials. 3. Select Sign in. Expected: The application opens the account dashboard. Actual: The loading indicator remains visible and the dashboard does not open. Frequency: Reproduced on three consecutive attempts in the test environment. Impact: Affected users cannot access the application; no workaround confirmed. Severity: High, based on blocked access. Priority: Awaiting triage. Evidence: Recording shows submission at 00:08 and the unchanged screen at 00:30. Technical context: Redacted request details attached to the internal ticket.
Record the error text exactly when one appears. If the issue might expose another account’s data, use your security escalation process and restrict evidence access rather than putting sensitive details in a public issue.
2. UI and layout bug report example
Include the viewport or device size for a layout issue. A report about a hidden button needs to show which screen size and content cause it.
Title: Save button is hidden below the profile dialog on a narrow screen Environment: Example application, release 4.2; mobile browser; 390px viewport Steps to reproduce: 1. Open Settings, then Profile. 2. Enter a two-line display name and open the notification options. 3. Scroll to the bottom of the dialog. Expected: The Save button remains reachable. Actual: The dialog cannot scroll far enough to reveal the Save button. Frequency: Reproduced with the same viewport and content. Impact: Profile changes cannot be saved on the affected layout. Workaround: Complete the change in a wider desktop viewport. Severity: Medium. Priority: Awaiting triage. Evidence: Screenshot of the clipped dialog and recording of the scroll attempt.
Describe the blocked task before proposing a CSS fix. The engineer may find a different cause than the one suggested by the appearance.
3. Performance bug report example
“The page is slow” is difficult to investigate. State the action, dataset, approximate observed duration, and conditions. A few observations are evidence for the report, not a claim about performance for every customer.
Title: Exporting a filtered ticket list leaves the page unresponsive Environment: Example application, release 4.2; Chrome on Windows; test dataset of 500 tickets Steps to reproduce: 1. Open Tickets and apply the Unresolved filter. 2. Select Export CSV. 3. Attempt to open another ticket while the export runs. Expected: The export completes and the page remains usable. Actual: Ticket navigation stops responding for about 20 seconds in the observed test. Frequency: Reproduced twice with the same test dataset. Impact: Agents cannot continue their ticket work during the export. Workaround: Export a smaller filtered list. Severity: Medium. Priority: Awaiting triage. Evidence: Recording shows the export at 00:05 and navigation becoming responsive at 00:25. Technical context: Sanitized performance trace attached if engineering requests it.
Include whether the issue also happens on another network or with a smaller dataset if you have tested that. Mark untested possibilities as unknown.
4. API error bug report example
For an integration issue, record the endpoint, method, response status, and a sanitized request example. Share credentials through your approved secret-management process, never through the bug report.
Title: Ticket creation returns an error when an optional field is omitted Environment: Example application's test API, version v2 Steps to reproduce: 1. Use an authorized test API client. 2. Send POST /v2/tickets with the required subject and description fields. 3. Omit the optional external_reference field. Expected: A ticket is created and the API returns the documented success response. Actual: The API returns HTTP 500; no ticket appears in the test dashboard. Frequency: Reproduced with two different sanitized test payloads. Impact: The affected integration cannot create tickets with this payload shape. Workaround: A populated external_reference succeeded in the observed test. Severity: High for affected integrations. Priority: Awaiting triage. Evidence: Sanitized request and response; request timestamp and correlation ID.
Check the application’s actual API documentation before calling a field optional or a response incorrect. This example illustrates the report structure, not Screendesk’s API contract.
5. Cross-browser bug report example
A browser comparison is useful when it holds the task and input constant. Include exact browser versions in your real report.
Title: Attachment preview stays blank in one browser Environment: Example application, release 4.2; Safari and Chrome on the same Mac Steps to reproduce: 1. Open the same test ticket in each browser. 2. Select the attached sample PDF. 3. Wait for the preview to load. Expected: The PDF preview is visible in each supported browser. Actual: Safari shows a blank preview; Chrome displays the same file. Frequency: Reproduced after reloading the ticket. Impact: Affected agents cannot review the attachment inside the application. Workaround: Download the file or use the browser where preview succeeded. Severity: Medium. Priority: Awaiting triage. Evidence: Screenshots from both browsers and their version numbers.
Confirm the browser is supported. An unsupported environment can still be worth documenting, but it should not be presented as a confirmed regression in the supported product.
6. Data validation bug report example
Use synthetic values to demonstrate validation problems. Record both the invalid input and the application’s response without copying personal customer data.
Title: Contact form accepts an email address without a domain Environment: Example application, release 4.2; Chrome; test workspace Steps to reproduce: 1. Open Add contact. 2. Enter Test Contact and an email value of sample@. 3. Select Save. Expected: The form explains that a complete email address is required. Actual: The contact is saved without a validation message. Frequency: Reproduced with the same synthetic value. Impact: Invalid contact data can enter the workflow and prevent later communication. Workaround: Review the address before saving and correct invalid test records. Severity: Medium. Priority: Awaiting triage. Evidence: Screenshot of the form and the saved test record.
Game testing bug report example
A game report needs the build, platform, level or checkpoint, input sequence, and relevant save state. This example is fictional and can be filed in any configured tracker.
Title: Character remains immobilized after closing the map at checkpoint B Environment: Fictional game test build 24.1; PC; controller configuration attached Starting state: Supplied test save at checkpoint B; character can move Steps to reproduce: 1. Load the supplied save and move the character forward. 2. Open the map using the recorded controller input. 3. Close the map and try moving in each direction. Expected: Normal movement resumes after the map closes. Actual: Character stays in place; camera movement still responds. Frequency: Record observed attempts and outcomes. Impact: Progress blocked at this checkpoint in the tested sequence. Evidence: Recording, save reference, input configuration, and logs if relevant.
Distinguish an input or animation issue from a complete game freeze. A timestamp and save reference are often more useful than a guessed engine diagnosis. Mark platform comparisons and any restart workaround as untested unless you checked them.
Adapt the report to the destination tracker
Engineering teams and public projects often set their own reporting rules. Read the destination’s guidance and use its required structure; the table summarizes what each source emphasizes.
| Destination | What its guidance emphasizes | What to watch for |
|---|---|---|
| Mozilla Bugzilla | Clear summary, reproduction steps, expected and actual results, and relevant context | Separate observations from speculation and separate issues into separate reports |
| GitHub issues | Markdown issue templates or structured issue forms configured by each repository | Follow the repository’s contribution instructions; a checked box should describe a check you performed |
| Chromium | Problem description, detailed steps, expected behavior, browser comparisons, and a simplified test where possible | Use the dedicated security route for a suspected vulnerability |
| Apple Feedback Assistant | One issue per report, descriptive titles, steps, expected and actual results, sample projects, and attachments | The app can attach on-device diagnostics, which differs from uploading evidence through the website |
| Visual Studio feedback | Similar-report search, reproduction steps, optional screenshots, and diagnostic recording | Review attachments before submitting and respond to follow-up requests |
| Jira | Capturing, assigning, prioritizing, and moving bugs through a configurable workflow | Fields and statuses depend on the team’s configuration; do not assume a universal severity field or SLA |
| Stack Overflow | Code that is minimal, complete, and tested to reproduce the problem | It is a question-and-answer site, not the product’s bug tracker; the answer may correct your own code |
Two habits from these sources help in any tracker. Supply a shared input, such as a minimal test page, sanitized fixture, or sample project, so the receiver does not need access to a private site; inputs like a table with twelve numbered rows make a missing row unambiguous. Then reduce the case and retest it to confirm it still shows the problem. Supply commands and logs as text, with secrets removed.
How support can hand a bug report to engineering
- Capture the customer’s task. Ask what they were trying to do, what happened, and whether they can repeat it. Avoid making them guess the technical cause.
- Add visual evidence. Request a recording of the relevant steps or use a video support call with screen sharing when live investigation is appropriate.
- Write a reproducible report. Attach the recording, reference the useful timestamps, and keep expected and actual results separate. Our bug reporting best practices cover turning notes into a finished report.
- Link the original support ticket. Keep customer communication and engineering investigation connected. Teams using Zendesk can review Screendesk’s Zendesk integration.
- Track verification. After a proposed fix, repeat the recorded steps in the corrected version and document the outcome.
Screendesk for customer support teams connects visual troubleshooting workflows through screen recordings, video calls, and support integrations. A recording adds context; the report remains the place to state the impact, reproduction steps, and next action.
Common questions about bug report examples
What is a good bug report title?
A good title describes the action and failure, such as “Export CSV leaves the ticket list unresponsive.” Avoid titles such as “Broken” or “Urgent bug” that omit the affected task.
What is the difference between severity and priority?
Severity describes the impact of the problem. Priority describes when the team intends to address it. A visible cosmetic issue can receive high priority for a launch even when its severity is low.
What is a minimal reproducible example?
It is the smallest complete input, page, or code sample that still shows the problem when someone else runs it. Remove unrelated content, retest after each reduction, and paste code as text rather than screenshots or a link to a large private project.
Can a customer submit a report without technical logs?
Yes. Clear steps, expected and actual results, the environment, and a recording can provide a useful starting point. Add developer logs only when they are relevant and can be shared safely.
