Bug Report Draft
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Keep it specific enough for triage queues and duplicate searches.
Name the smallest product surface that should own the first triage pass.
Record the environment where the bug first appeared and any setup needed to reproduce it.
One action per line; include special setup only when it changes the result.
Keep the expected result separate from the actual observation.
Separate facts from guesses so engineers know what was observed.
Choose the level that matches user harm before any scheduling decision.
Use customer or workflow impact rather than an internal guess at priority.
This helps triage distinguish deterministic defects from intermittent signals.
One reference per line; keep customer or secret data out of pasted links.
Sanitize tokens, email addresses, customer identifiers, and payload secrets before filing.
Use "None known" when there is no reliable workaround.
A narrow first-seen range helps teams find candidate changes faster.
These labels are copied into the triage table and JSON without changing the report text.
{{ result.markdown }}
Field Value Triage use Copy
{{ row.field }} {{ row.value }} {{ row.use }}
Gate Status Review note Copy
{{ row.gate }} {{ row.status }} {{ row.note }}
Tags: Devtools, Diagnostics
Export to PDF Fullscreen
Customize
Advanced
:

A useful bug report turns a surprising product behavior into a report that another person can reproduce, triage, and discuss without guessing. The important parts are the symptom, the affected area, the environment, the exact steps, the expected behavior, the actual behavior, and the evidence that supports the observation.

Good reports avoid two common traps. A vague title such as "broken" does not help a triage queue, and a long narrative without ordered steps does not give an engineer a clear path to repeat the issue. A concise title plus a small reproduction path usually helps more than a broad theory about the root cause.

A bug report is not a proof of root cause. It is a structured handoff that lets the next person decide whether the issue is reproducible, how serious it looks, who should own it, and what evidence should travel with the tracker item.

Technical Details:

Bug reporting works best when it separates facts from interpretation. Reproduction steps describe actions, expected behavior describes the intended result, and actual behavior records what was observed. Severity and impact then explain harm without pretending to decide scheduling priority for the whole team.

Environment details matter because many defects depend on browser version, app build, operating system, account role, tenant data, feature flags, or a specific record state. A report that works only for an admin account with one failed export is different from a report that affects every user on every workflow.

The generator keeps the report structure close to common issue-tracker templates. It normalizes one action per reproduction line, turns comma-separated tracker labels into a list, and keeps diagnostics in a text block so status codes, console messages, or request notes remain readable after copying.

Field What it captures Why it matters
Bug title Concise symptom plus affected surface Helps queues, searches, and duplicate checks find the right issue.
Affected area Product, page, endpoint, workflow, or module Gives the first owner a likely routing target.
Environment Browser, build, device, account role, tenant, or data setup Explains where the behavior first appeared and what setup may be required.
Steps to reproduce Ordered actions, one meaningful action per line Lets another tester or engineer repeat the same path.
Expected and actual behavior The intended result and the observed result, kept separate Prevents assumptions from hiding the real mismatch.
Severity and impact User harm, blocked workflow, data risk, or workaround context Supports triage without turning severity into a release priority.
Evidence and diagnostics Screenshots, recordings, request IDs, related tickets, logs, and status codes Gives debugging context beyond the written steps.
Workaround and regression window Temporary path, first affected build, last known good build, or date range Helps teams reduce user harm and narrow candidate changes.

The readiness check is deliberately simple. Required gates focus on the title, environment, reproduction steps, and expected-vs.-actual split. Review gates call out useful but sometimes optional context such as evidence, diagnostics, impact, and regression notes.

Gate Ready condition Review condition
Specific title Title has enough detail and is not a generic word such as bug, issue, problem, or broken. Replace generic wording with a symptom and affected area.
Reproduction steps At least two normalized steps are present. One step is marked for review; no steps block readiness.
Expected vs. actual Both expected behavior and actual behavior are filled. Missing either side blocks the core report.
Evidence attached Evidence links, attachments, or diagnostic text are present. Blank evidence is a review note, not a hard stop.
Sensitive data scrub No obvious token, password, secret, bearer value, or email pattern is detected in evidence fields. A pattern match asks for manual scrubbing before filing.

The sensitive-data check is a pattern screen, not a security scanner. It can catch obvious secrets or personal data in pasted evidence and diagnostics, but it cannot understand every customer identifier, payload value, screenshot, or attachment name.

Everyday Use & Decision Guide:

Start with the smallest affected area and the shortest reproduction path that still triggers the issue. A good first pass is a title that names the symptom, an environment that names the build and browser or device, and steps that another person can follow without asking what screen, account, or record to use.

Use Severity for harm, not for scheduling politics. Critical fits outages, data loss, security issues, or no-workaround failures. Major fits blocked or unreliable important workflows. Minor and Trivial fit degraded behavior, confusing polish, typos, or cosmetic defects with limited risk.

  • Choose Always with these steps only when the same path consistently triggers the behavior.
  • Use Intermittent / sometimes when timing, data state, network conditions, or retries change the result.
  • Add Evidence links or attachments for screenshots, recordings, request IDs, support tickets, or related tracker items.
  • Paste only short sanitized text into Logs or diagnostics. Remove tokens, passwords, customer identifiers, and private payload details first.
  • Fill Regression or first seen when a release date, build number, or last known good version is known.

The result tabs serve different handoff needs. Ticket Markdown is the copy-ready report body. Triage Fields is a compact table for routing, filtering, and CSV or DOCX handoff. Repro Checklist shows which gates are ready, need review, or need work. JSON keeps the same report and readiness data in a structured format.

The page prepares the report artifacts from the values in the form. It does not create an issue, assign an owner, upload attachments, search for duplicates, or verify that the bug is truly caused by the suspected component.

Step-by-Step Guide:

  1. Enter a Bug title that names the symptom and affected surface, such as a button staying disabled after a failed export.
  2. Add the Affected area that should own the first triage pass.
  3. Describe the Environment, including browser, build, operating system or device, account role, tenant, and data setup when relevant.
  4. Write Steps to reproduce with one action per line. Keep setup details only when they change the result.
  5. Fill Expected behavior and Actual behavior as separate facts.
  6. Choose Severity and Reproducibility, then explain the user or workflow harm in Impact.
  7. Open Advanced for evidence, diagnostics, workaround, regression window, and tracker labels.
  8. Review Repro Checklist. Clear Needs work rows before copying Markdown into a tracker.

Interpreting Results:

The summary strip is a readiness signal, not a bug verdict. Ready to triage means the core report gates are filled and no review notes remain. Ready with notes means the core fields are usable, but optional context such as evidence or regression details could improve the ticket. Needs core details means at least one required gate should be fixed before filing.

The severity badge and step-count badge help with quick scanning. They do not prove impact, priority, or ownership. A major intermittent bug with a strong diagnostic trace can deserve fast attention, while a critical label with no environment or steps still needs more detail.

Result cue Meaning What to check next
Ready to triage Required and review gates are currently satisfied. Copy the Markdown after confirming evidence is sanitized.
Ready with notes No hard stop remains, but one or more review rows could improve the report. Check evidence, diagnostics, impact, and regression context.
Needs core details A required report section is missing or too vague. Fix the rows marked Needs work in the checklist.
Sensitive data scrub shows Review The evidence or diagnostics text matched a simple secret or personal-data pattern. Remove tokens, passwords, bearer strings, emails, and private payload values before filing.
Triage Fields The report is summarized into field, value, and triage-use rows. Use it when a team needs a table, CSV, or document handoff.

The Markdown output is usually the best tracker body. The tables and JSON are useful when a workflow needs structured review, but the report still depends on the quality of the facts entered in the form.

Worked Examples:

A reproducible export failure

An admin reports that a retry button stays disabled after a failed export. The environment names Chrome, macOS, the staging build, and an admin account with one failed export. Four ordered steps lead to a clear expected result and actual result. With impact, evidence, diagnostics, workaround, and regression context filled, the checklist can reach Ready to triage.

A vague report that should not be filed yet

A report titled broken with one step and no environment will trigger core-detail warnings. The better version names the surface, such as Export history retry stays disabled, then adds the account role, build, failed row state, expected confirmation dialog, and observed disabled button.

An intermittent checkout issue

A tester sees a checkout total change only on some retries. Intermittent / sometimes is more honest than Always with these steps. The evidence should include the timestamp, request ID, browser, cart state, and any safe diagnostic excerpt so the team can compare attempts rather than treating the issue as deterministic.

FAQ:

Does the generator decide the final priority?

No. It records severity, reproducibility, and impact so a team can triage faster. Priority still depends on roadmap timing, affected users, release risk, and team policy.

What should go in diagnostics?

Use short sanitized excerpts such as status codes, request IDs, console errors, or log lines that explain the observed behavior. Do not paste secrets, passwords, tokens, customer identifiers, or full private payloads.

Why are expected and actual behavior separate?

Keeping them separate prevents the report from mixing the product requirement with the observation. That makes it easier to confirm whether a fix changed the right behavior.

Can a report be useful if the bug happened once?

Yes, if the report is honest about reproducibility and includes enough environment, evidence, diagnostics, and timing detail for later comparison. It should not claim deterministic reproduction until the same steps have been retested.

Glossary:

Reproduction steps
Ordered actions another person can follow to trigger the same behavior.
Expected behavior
The result that should happen according to the product behavior, requirement, or accepted workflow.
Actual behavior
The result that was observed, including messages, missing UI, wrong data, or status codes.
Severity
A harm label for the defect itself, separate from scheduling priority.
Regression window
The first affected build, last known good build, release, or date range that narrows where the bug may have appeared.

References: