14 Bug Report Templates (With Copy-Paste Forms and Screenshots)

Engineering teams resolve bugs 63% faster when the initial report contains reproduction steps, environment details, and a screenshot, according to a 2024 survey of 1,200 dev teams published by LinearB. The problem is most users never include any of that. They write "the button is broken" and close the tab.

TL;DR:

• A good bug report has seven fields at most: title, steps, expected, actual, environment, severity, and evidence.
• Minimum viable templates (3 fields) get more submissions. Maximum signal templates (10 fields) get better submissions.
• Copy any of the 14 templates below into Feedbask's widget builder, or use them as-is in Notion, Linear, or a shared form.

Anatomy of a Good Bug Report

Every useful bug report answers four questions: what broke, how to reproduce it, what was expected, and what environment it happened in.

If a field doesn't answer one of those four questions, cut it. The classic mistake is asking for a "priority" or "severity" rating from the user. Users always pick the highest option. That data is noise. Let your triage owner assign severity after the report lands.

Evidence matters more than prose. A 15 second screen recording or a single screenshot replaces three paragraphs of guessing. If your tool doesn't capture browser console logs or network requests automatically, you are making your engineers work harder than they need to.

Minimum Viable Fields vs Maximum Signal

Shorter forms get more submissions, longer forms get more useful submissions. Pick based on who's reporting.

Here's the tradeoff in numbers from our own widget analytics across 4,300 installs:

For a public changelog page or marketing site, use 3 fields. For a paid app with a known user base, use 5 to 7. For an internal QA team, use 10. Don't mix audiences on the same form.

Web SaaS Templates (4)

These four cover the most common web app scenarios: dashboard errors, billing failures, integration breaks, and visual glitches.

Template 1: Dashboard Error

Who files it: any signed-in user hitting an unexpected state.

Fields: Title, Current page URL (auto-captured), Steps to reproduce, What did you expect, What happened instead, Screenshot, Browser and version.

Example filled-in bug:

• Title: Export CSV button spins forever on Customers page
• URL: /app/customers?segment=active
• Steps: 1) Go to Customers 2) Filter by Active 3) Click Export CSV
• Expected: File downloads within 10 seconds
• Actual: Button shows spinner for 2+ minutes, no file, no error
• Browser: Chrome 128 on macOS 14.6

Template 2: Billing or Subscription Bug

Who files it: anyone who sees an incorrect charge, plan, or invoice.

Fields: Title, Account email, Plan you are on, Expected charge, Actual charge, Invoice ID, Screenshot of invoice.

Always let the user attach their invoice PDF. Stripe invoice IDs (prefixed in_) cut your investigation time in half because you can paste them directly into the dashboard.

Template 3: Integration or Webhook Failure

Who files it: power users of your Zapier, Slack, or API connector.

Fields: Title, Integration name, Last time it worked, First time it failed, Error message (if shown), Sample payload, Your user ID.

Template 4: UI or Visual Glitch

Who files it: anyone spotting layout breaks, text overflow, or theme bugs.

Fields: Title, Screenshot (required), Device and screen width, Browser, Dark or light mode.

Make screenshot upload mandatory here. A visual bug without a visual is almost always unfixable from the report alone.

Mobile App Templates (3)

Mobile bugs need device class, OS version, and app build number. Without those three you are guessing.

Template 5: Crash Report

Who files it: users who just reopened the app after a hard exit.

Fields: Title, What were you doing, Device model, OS version, App version, Crash ID (if Crashlytics is wired up).

Pre-fill device and OS from the user agent. Never ask the user to type "iPhone 14 Pro, iOS 17.5.1" manually. They will type "iphone" and leave.

Template 6: Offline or Sync Bug

Who files it: users on patchy connections or after coming back online.

Fields: Title, What you did offline, What was missing when you came back, Network type when it happened, Sync timestamp.

Template 7: Push Notification Issue

Who files it: users who missed a notification or got a duplicate.

Fields: Title, Notification type, Expected time, Received time (or none), Device notification settings (checklist).

Include a checklist like "Notifications enabled for this app: Yes/No" to filter out OS-level permission issues before they hit engineering.

Browser Extension Templates (3)

Extensions have a unique problem: they run across every site on the web, so the "where" field is the most important input.

Template 8: Site-Specific Break

Who files it: users reporting the extension fails on a specific domain.

Fields: Title, URL (exact), Extension version, Browser and version, What you expected the extension to do, What happened, Screenshot.

Template 9: Permissions or Install Failure

Who files it: new users who couldn't get the extension running.

Fields: Title, Install step that failed, Browser, OS, Screenshot of error dialog.

Template 10: Conflict with Another Extension

Who files it: users noticing the bug only appears with certain other extensions installed.

Fields: Title, List of other extensions enabled, Steps to reproduce, Result with yours disabled, Result with others disabled.

This is the one template where asking for a list of competing extensions is genuinely useful. Most conflicts show up in the same three or four tools.

Agency and Client Templates (4)

Client-facing bug reports live in a different universe. The reporter isn't a user, they're a stakeholder with opinions. Your template has to separate fact from feeling.

Template 11: Client Discovered Bug (Production)

Who files it: the client's QA lead or project manager.

Fields: Title, Environment (staging, production, UAT), Reproduction steps, Screenshot or video, Business impact in one sentence, Blocking go-live? Yes/No.

Template 12: Pre-Launch QA Bug

Who files it: internal testers before handoff.

Fields: Title, Jira or Linear ticket link, Steps, Expected per spec, Actual, Browser matrix (checklist of tested browsers), Severity.

Template 13: Post-Launch Hotfix Request

Who files it: anyone after deployment when something is on fire.

Fields: Title, Revenue or user impact estimate, First observed at, Affected user segments, Temporary workaround attempted.

Template 14: Accessibility Bug

Who files it: testers or end users running screen readers or keyboard navigation.

Fields: Title, Assistive technology used, Steps, Expected behavior per WCAG guideline, Actual behavior, Link to the specific SC (success criterion).

How to Embed with Feedbask

All 14 templates drop into the Feedbask widget builder without custom code.

Open /product/bug-report-widget, pick the template that matches your audience, and drag fields to match the lists above. The builder auto-fills URL, browser, device, and user ID so your users never fill in metadata manually. Screenshot capture runs in the browser with no extra dependency.

Paste the snippet into your app:

<script src="https://cdn.feedbask.com/widget.js" data-widget="YOUR_ID" defer></script>

For a separate bug-only surface (useful when you already collect feature requests elsewhere), create a second widget and gate it behind a help menu item. Full setup walkthrough lives in the docs.

If you're running an agency workflow, create one widget per client project, set a custom email destination, and route the submissions into each client's shared channel. That keeps your internal triage separate from their internal team.

FAQ

How many fields should a bug report form have?

Three to seven. Three for public submissions from anonymous visitors, seven for authenticated users inside a paid product. Anything above seven is for internal QA only.

Should I require users to rate severity?

No. Users always pick high or critical because they want to be taken seriously. Severity is a triage decision made by whoever owns the bug backlog, not the reporter.

What about asking for a video instead of a screenshot?

Offer both, require neither. Video uploads have a 60 to 70% drop-off on mobile because the recording flow is slow. A screenshot plus steps gets you 90% of the way there.

Do I need different templates per plan tier?

Only if your paid users hit features your free users never see. Otherwise, one thorough template and one minimal template cover everything.

Can I auto-assign severity from keywords?

Yes, but sparingly. Auto-flag reports that contain "payment", "data loss", "login", or "security" as high priority for initial review, then let a human decide. Pure keyword routing misses context.

How do I prevent duplicate bug reports?

Show a live search bar inside the widget that queries existing public bugs as the user types a title. Feedbask's bug widget does this by default when you enable the public changelog. Duplicates drop by roughly 30 to 40% in our own data.

Ready to stop chasing down "the button is broken" reports? Pick a template, install the widget, and ship faster. Start free at feedbask.com/auth.