Bug report template for Jira

When a team spends more time chasing missing details than fixing code, the problem is rarely the bug itself. It is the bug report. A Jira Bug template gives every report the same shape, so the reporter writes the right things once and the engineer reads them once. Copy the template on this page straight into a Jira issue, or read on for what to capture, a strong-versus-weak example, and how to turn the structure into a reusable template with Issue Templates for Jira Cloud.

What is a bug report template?

Instead of starting from a blank Description field every time, the reporter fills a framework that already asks for the title, the reproduction steps, the expected and actual behavior, the severity, the affected area and the supporting files. The framework is the difference between a ticket an engineer can act on immediately and one that bounces back with “cannot reproduce, need more info.”

Bug report example: strong vs weak

The fastest way to see why structure matters is to compare two reports of the same problem. The filled-in example in the panel above is a strong report; here is the same defect logged well and badly.

A weak report looks like this:

• Title: “App not working.”
• No steps to reproduce.
• No expected or actual result.
• No severity.
• No screenshot or log.

A strong report looks like this:

• Title: “Error displayed when saving a draft email.”
• Steps to reproduce: log in, open the email composer, write a draft, click Save.
• Expected result: the draft saves and a confirmation message appears.
• Actual result: the save fails with no error message.
• Severity: Major, with a workaround (manual copy out before refresh).
• Attachment: a screenshot of the blank confirmation area plus the console log.

Both describe the same defect. Only the second one lets an engineer reproduce it in minutes.

What to include in a bug report

A clear and descriptive title. Compare “App not working” with “Error displayed when saving a draft email.” The second tells triage what to expect before they open the ticket.

Description. A one or two sentence framing of the issue and its business context, for example “We identified a bug in the checkout flow that blocks paying customers from completing an order.”

Steps to reproduce. Numbered, top to bottom, with no skipped clicks. For example: log in to the application, open the Settings menu, change the language to French, observe that the dashboard text overlaps.

Expected vs actual results. State them side by side. Expected: the file uploads successfully with a confirmation message. Actual: the upload fails with no error message. The gap between the two is the bug.

Severity level. A dropdown keeps triage fast and consistent: Critical prevents core functionality such as login, Major impacts significant functionality but has a workaround, Minor covers cosmetic or non-urgent issues.

Customer(s) impacted. Who is affected and what is the business impact. This is what turns a backlog item into a prioritized one.

Part of the software impacted. Login, Dashboard, Checkout, Settings, and so on. Routing the ticket to the right area saves a triage hop.

Environment. Browser and version, operating system, app build, for example Chrome 115 on Windows 10 running build 2.3.5. Engineers reproduce locally without guessing. This field is worth treating as mandatory: most “cannot reproduce” replies trace back to a missing environment.

Date and time observed. “This occurred on May 20th at 3:45 PM while testing checkout” helps correlate the report with deploys and logs.

Attachments. A screenshot of the error, a short video of the bug occurring, or the exact text of a crash log or stack trace. Anything that makes the defect obvious at a glance.

How to write a good bug report

• Understand the issue before reporting. Reproduce it yourself first so the steps are accurate and consistent.
• Stick to facts. Describe what happens, not your guess at the root cause or the fix.
• Keep each report focused on one issue. Do not bundle several bugs into one ticket.
• Note the reproduction rate. Say whether the bug is consistent or intermittent.
• Use visual aids wisely. Annotate screenshots to point at the exact problem, trim videos to the relevant moment, and attach logs only when they relate directly.
• Collaborate when unsure. Ask a teammate to confirm details before filing.

Bug report vs bug tracking in Jira

A bug report is a single, well-structured ticket. Bug tracking is the workflow around it: triaging incoming reports, prioritizing by severity, assigning an owner, and following each defect from open to resolved without anything slipping. The two depend on each other. Reliable bug tracking in Jira starts with consistent reports, because dashboards, filters and severity-based queues only work when every Bug carries the same fields. Standardize the report with the template above and the tracking layer, your JQL boards and burndown, becomes trustworthy by default.

How to use this template in Jira

Capturing this structure by hand on every bug is exactly the busywork a template removes.

1. Install Issue Templates for Jira Cloud from the Atlassian Marketplace. It is free for up to 10 users.
2. Build a Bug issue with these fields and save it as a template from the issue menu. The creating issue templates guide walks through it.
3. Add variables for the parts that change per report, such as a Severity dropdown or a Part of the software impacted picklist, so reporters choose instead of retype. See template variables.
4. Launch new bugs from the template, with a prefilled create screen ready to submit.

Bug template variants

The same base adapts to the kind of defect you log. A functional bug focuses on a broken core feature with exact reproduction steps. A UI bug captures misalignment, spacing and broken layouts. A performance bug records crashes, slow loads and lag. A security bug documents a vulnerability and its blast radius. A compatibility bug records the device, browser or OS where behavior differs. An accessibility bug covers assistive-technology and keyboard issues. Each variant simply tweaks the Severity dropdown and adds a field or two, which is trivial once the base template exists.

Frequently asked questions

What should a Jira bug report include? A strong Jira bug report includes a clear title, steps to reproduce, expected versus actual behavior, severity, the affected area, environment details, the date and time observed, and supporting attachments such as a screenshot or console log.

What is the difference between a bug report and bug tracking in Jira? A bug report is the structured record of a single defect. Bug tracking is the workflow around it: triaging, prioritizing by severity, assigning, and following each bug from open to resolved. A consistent bug template feeds reliable bug tracking because every ticket carries the same fields.

How do I create a reusable bug template in Jira? Install Issue Templates for Jira Cloud, build one Bug issue with the fields on this page, save it as a template, then add variables for the parts that change so your team launches consistent bugs in one click.

What severity levels should a bug template use? Most teams use three: Critical for issues that block core functionality such as login, Major for significant problems that have a workaround, and Minor for cosmetic or low-urgency defects.

Related templates

Pair the bug template with the rest of your software workflow: the Story template, Task template, Epic template and Feature request template. Or browse the full template library for matching formats across software, ITSM and support work.