Bug report generator

How to use the generator

Fill in the fields from top to bottom. Five are required: the summary, the page address, the steps, the expected result and the actual result. Those five are the minimum a developer needs to see the problem for themselves. The environment fields are optional but save a round of questions, because a problem that appears only in one browser is a different problem from one that appears everywhere.

Choose Markdown if the report is going into an issue tracker that formats it, such as GitHub, GitLab or Jira. Choose plain text for email or a chat message. Press Write the report, check the output, then copy it or download it as a file.

If you change any field after writing the report, the output disappears until you write it again. That prevents an out-of-date report being copied by mistake.

Severity, explained

The severity list uses four levels, the same ones used in our own reports.

Severity describes impact, not urgency. A low-severity typo on the home page might still be fixed first because it is quick and highly visible. Keeping the two ideas separate makes the defect list easier to sort.

Writing steps that reproduce

The steps field does most of the work. Start from a state anyone can reach, such as "Open the page in a private window", then list each action on its own line. Include the exact text you typed if it matters: a form that fails only with an apostrophe in the surname needs the surname in the steps. If the problem does not happen every time, say how often in the "How often" field and note anything that seemed to make a difference.

The template, for use without JavaScript

If the generator does not run, copy these headings into your email or issue and fill in each one.

Evidence that helps

A screenshot showing the problem with the address bar visible answers two questions at once. A short screen recording is better for anything involving movement or timing. If you can open the browser's developer tools, copy any red error messages from the console into the evidence field. Our guide to collecting test evidence explains how to capture each kind, and what to leave out, such as personal data in screenshots.

Where to send the report

The right destination depends on who will fix the problem:

• Your own developer or agency: use the issue tracker or channel you agreed with them, and Markdown if it supports formatting.
• A plugin or theme author: use their support forum or issue tracker, and include the plugin's version number and your CMS version in the environment field.
• A third-party service, such as a booking widget: contact their support with the report as plain text, and include your account reference.
• A website you do not own: use the site's contact page or feedback link. Keep the report short, polite and factual; the owner may not be technical.

Whichever route you use, keep a copy of the report and note when you sent it. If the problem is not acknowledged, the copy makes a follow-up quick.

Duplicate reports

Before writing a new report, check whether the problem has been reported already. In an issue tracker, search for the page or the error text. If it has, add your environment and evidence to the existing report instead of creating a second one. Two reports of the same defect split the conversation and can lead to two people fixing the same thing.

Privacy

The generator runs entirely in your browser. We never see the reports you write. If a report includes personal data, such as a customer's name in a screenshot, remove it before sharing the report with anyone who does not need it.