Skip to content
19 10240119 Tools

Copyable template

Bug Report Template

Copy a practical bug report template with reproduction steps, environment details, evidence, impact, support escalation, API variant, and privacy reminders.

Updated 2026-05-15

Use this structure when a teammate needs enough detail to reproduce a bug without a long back-and-forth. It works for product bugs, API issues, mobile problems, and support escalations where evidence matters more than blame.

Copyable Template

# Bug Report

## Summary
- One-sentence issue:
- Affected user, account, workspace, or environment:
- First seen:
- Current status: [new / repeated / intermittent / blocked]

## Steps to Reproduce
1. Start from:
2. Click or enter:
3. Continue with:
4. Observe:

## Expected Result
- What should happen:
- Why that result is expected:

## Actual Result
- What happened instead:
- Error text, code, broken screen, or wrong data:
- Does refreshing, retrying, or signing out change it?

## Environment
- Device and operating system:
- Browser or app version:
- Network or region if relevant:
- Account type, role, permissions, or test data:
- Feature flag, release version, or build number:

## Evidence
- Screenshot, screen recording, or log link:
- Console or network error:
- Relevant request ID, trace ID, or timestamp:

## Impact
- Who is affected:
- Frequency: [once / sometimes / every time]
- Workaround:
- Severity suggestion and reason:

## Notes for Triage
- Suspected area:
- Similar issue, ticket, or recent change:
- What has already been tried:

---

## Short Support Escalation Variant

Customer or reporter:
Issue:
Steps already tried:
Evidence link:
Business impact:
Needed next action:

---

## API Bug Variant

Endpoint:
Method:
Request sample with private values removed:
Expected response:
Actual status and response:
Headers or auth scope involved:
Request ID or timestamp:

Boundary reminder:
- Remove passwords, tokens, private customer data, and full payment details.
- Separate suspected causes from observed facts.
- Do not inflate severity; explain impact with evidence.

Useful variants

  • Web app bug with reproduction steps
  • Mobile app bug with device details
  • API bug with request and response samples
  • Support escalation for a customer-reported issue
  • Regression report after a release

How to adapt it

Replace bracketed text with your details, remove sections you do not need, and keep the final version short enough for the reader to act on.

FAQ

What makes a bug report useful?

A useful bug report has clear reproduction steps, expected and actual results, environment details, and evidence such as screenshots, logs, request IDs, or timestamps.

Should I include severity?

Yes, if your team uses severity. Keep it evidence-based: who is blocked, how often it happens, whether there is a workaround, and what customer or workflow is affected.

What private information should I remove?

Remove passwords, tokens, full payment details, private customer data, and anything not needed to reproduce the issue. Replace it with safe placeholders when possible.

What if the bug is intermittent?

Say it is intermittent, list how often you have seen it, and include timestamps or conditions. Intermittent reports are still useful when they include patterns and evidence.