How many required fields should a bug report form have?

Keep required human-entered fields to three or four — title, what happened, what you expected, and severity. Making technical fields like console logs required forces people to either skip them or paste something useless. Auto-capture those instead of requiring them.

Should severity be a dropdown or free text?

A dropdown or picker with defined levels. Free-text severity produces values like 'high?' and 'kinda bad' that can't be sorted or filtered. A fixed set (for example blocker, major, minor, trivial) with a one-line definition beside each keeps triage consistent.

How to Design a Bug Report Template Teams Actually Use

Q: What fields should a bug report template include?

At minimum: a specific title, numbered steps to reproduce, expected vs. actual result, environment (browser, OS, version, device), the exact URL or route, evidence (screenshot or recording plus console and network logs), severity, and reproducibility. Ask humans only for the first four in prose; capture the rest automatically.

To design a bug report template teams actually use, ask people only for what a human uniquely knows — a specific title, what happened, and what they expected — and auto-capture everything technical: the URL, environment, console errors, network requests, and timestamp. Every required free-text field you add lowers both completion rate and quality, so the shortest form that still lets a developer reproduce the bug is the best template you can ship.

What fields should a bug report template include?

A complete bug report carries enough for someone who has never seen the issue to reproduce it. That breaks into two groups: fields only the reporter knows, and fields a machine can collect. Design your template around that split.

Fields a human must supply (keep these short):

Title — one specific line: what broke, where. "Checkout button does nothing on the cart page" beats "bug".
What happened — the actual result, in the reporter's own words.
What you expected — the intended behavior. The gap between these two is the bug.
Severity — how badly it breaks the product, chosen from a fixed list.

Fields you should capture automatically (don't make people type these):

Steps to reproduce — the actions leading up to the report; reconstruct from the session where you can, or prompt for a numbered list.
Environment — browser, browser version, OS, device, and viewport size.
URL / route — the exact page, including query parameters.
Evidence — a screenshot or short recording, plus console errors and failed network requests.
Timestamp — when it happened, so it can be matched to logs and deploys.
Reproducibility — always, sometimes, or seen once.

The distinction matters because the technical fields are exactly the ones people skip, guess at, or get wrong — and they're also the ones a browser can read directly.

How to design a bug report template step by step

Start from the fix, not the form. List what a developer needs to reproduce and diagnose a typical bug, then work backward to the fields that supply it. If a field doesn't help someone reproduce, triage, or route the bug, cut it.
Make the human section tiny. Title, what happened, what you expected, severity. Four fields is a form people finish; twelve is a form they abandon or fill with "n/a".
Auto-capture the technical fields. Read the URL, browser, OS, viewport, console log, and network activity from the session instead of asking. This is the single biggest quality lever, because it removes the fields most likely to be wrong when typed by hand.
Use pickers, not free text, for anything you'll sort by. Severity and reproducibility should be dropdowns with defined options. Free text can't be filtered, and it invites values no one can compare.
Set smart defaults. Pre-fill environment and URL, default severity to "minor" rather than blank, and pre-select the current project or component. A partially filled form is finished faster and more accurately.
Add a duplicate check at intake. Search open tickets by title and URL before creating a new one, and surface likely matches so the reporter can confirm an existing bug instead of splitting the signal across two tickets.
Redact PII and secrets by default. If the template captures console output, network payloads, or screenshots, strip tokens, auth headers, and personal data automatically — don't rely on the reporter to remember.

Required vs. optional fields: how to avoid empty tickets

The temptation is to mark every useful field required so nothing is missing. In practice, over-requiring backfires: people either abandon the form or type filler to get past the gate, and you end up with tickets that look complete but reproduce nothing.

A more reliable rule:

Require only what a human uniquely knows — title, what happened, what you expected, severity.
Auto-fill everything technical so it's present without being a gate.
Leave genuinely optional context optional — account role, related tickets, workaround — and let people add it when they have it.

The goal is a template where a complete, reproducible ticket is the path of least resistance, not an obstacle course.

How to auto-capture evidence instead of asking for it

The fields that decide whether a bug gets fixed — environment, console errors, and network failures — are the ones a reporter is least equipped to provide. Most people don't know how to open developer tools, let alone export a HAR file, so asking for them in a template just guarantees blank fields.

Capturing them from the session solves this. When a report is filed from inside the product, the tool already has the URL, the browser and OS, the viewport, the recent console log, and the network requests around the moment the bug was flagged. In-app and right-click bug reporting exists precisely to attach that state automatically — Klavity Snap lets someone right-click to file a bug and ships it with the screenshot, console, network, and environment already attached, so the template's technical fields fill themselves. That turns "cannot reproduce" back-and-forth into a ticket a developer can act on immediately. For the reporter's side of the format, see how to write a bug report developers will actually act on.

Bug report template examples by tool

Most trackers support templated intake; the mechanics differ:

GitHub Issues — add Markdown or YAML issue forms under .github/ISSUE_TEMPLATE/. YAML forms let you define typed inputs and mark specific ones required, which is closer to a real form than a Markdown checklist.
Jira — use a dedicated Bug issue type with custom fields (severity, environment, steps) and configure which are required per screen scheme. Keep required custom fields minimal to avoid the abandonment problem.
Linear — use issue templates to pre-populate the description structure and default labels, and lean on labels rather than many custom fields for severity and area.

Whichever tool you use, the design principles are the same: few required human fields, structured pickers for anything you sort by, and evidence attached rather than requested. For a deeper look at filing directly to each tracker, see the Klavity blog.

Common bug report template mistakes

Too many required fields. The fastest way to kill report quality is to gate submission behind a dozen inputs. People route around gates.
Free-text severity and priority. Unsortable, incomparable, and impossible to build SLAs on. Use fixed levels with one-line definitions.
Asking users for console logs and HAR files. Most reporters can't produce them; capture from the session instead.
No duplicate check. Without an intake search, the same bug lands three times and the triage cost triples.
No default state. Blank severity and blank environment mean every ticket needs a follow-up before it can even be triaged.

Design the template so the easy path produces a reproducible ticket, and quality stops depending on how much each reporter happens to know.