A useful Jira bug report states the failure clearly, gives reproducible steps, compares expected and actual results, and records the affected environment and impact. Put that information in the description, then use the fields configured by your team for priority, ownership, components, and versions.
There is no universal set of required Jira bug fields. Your Jira product, space or project, work type, and administrator configuration determine the form. This guide provides a field map, a copyable description, a filled example, and a triage checklist.
A recording-to-Jira handoff that survives triage
A useful attachment tells the reviewer where to look. For the fictional CSV-export report below, the handoff should explain the starting state, the selected format, the visible error, and the open engineering question. A video without that description adds another object to the ticket without making the investigation clear.
Evidence note — fictional CSV export case 00:05 — saved report and starting state 00:18 — CSV selected 00:24 — visible export error Written result: no CSV file downloaded Known scope: this tested report and session only Open question: why does this CSV path fail? Access check: intended triage owner can open the recording Customer-update owner: support, until a new agreement is made
Keep the original support reference in the saved Jira description. Ask the receiving owner to confirm that the evidence is accessible and the reproduction steps are complete. If those checks fail, repair the handoff before describing the ticket as ready for investigation. For the full investigation record, use the troubleshooting report template.
Jira bug fields: what to put where
| Field or report detail | What to provide | Example or check |
|---|---|---|
| Title / Summary | Action, failure, and relevant condition | Saved report export fails when CSV is selected |
| Space / Project | The team or product area that owns the work | Confirm the intended destination before submitting |
| Work type / Issue type | Bug or the team’s configured defect type | Ask the administrator if the expected type is unavailable |
| Description | Starting state, steps, expected and actual results, evidence, and impact | Use the template below |
| Environment | Relevant app version, browser, OS, device, role, and test conditions | Include in the description if no separate field is shown |
| Priority | The team’s triage decision based on relative importance | Explain impact instead of assuming every report is highest priority |
| Severity, if configured | The observed effect under the team’s definitions | Record blocked workflow, data impact, scope, and workaround |
| Assignee | The agreed investigation owner or routing destination | Use triage if the correct owner is unknown |
| Affects versions | Versions in which the problem is observed | Record only confirmed affected versions |
| Fix versions | The release version for the work or fix | Confirm with the team; do not confuse it with the affected release |
| Components / Labels | Existing team categories that help routing or search | Follow conventions instead of creating unnecessary variants |
| Attachments / Links | Relevant evidence and related reports | Check that the assignee can access the evidence |
Atlassian’s version documentation distinguishes Affects versions, where the problem occurs, from Fix versions, where the work is released. Version fields depend on the space’s version setup.
Do not treat severity as a field available in every Jira configuration. If your form lacks a place for an essential reporting detail, put it in the description and ask the team whether a structured field would improve routing or reporting.
How to raise a bug in Jira Cloud
- Search for a related report so you can add new evidence to an existing investigation when appropriate.
- Select Create and confirm the destination space or project.
- Select Bug or the team’s configured work or issue type.
- Enter the title and description, then complete the fields required by the visible form.
- Add relevant evidence, check prefilled values, and submit.
- Open the saved work item and confirm the description, links, and routing are correct.
Atlassian’s current creation guide uses Space, Work type, and Title; older interfaces or documentation may use Project, Issue type, and Summary. Expand to the full form when you need fields outside Quick Create. Jira Service Management and other products may have a different creation experience.
For a broader walkthrough covering other ticket types, use how to create an issue in Jira. The rest of this guide focuses on making a defect report actionable.
Copyable Jira bug-report description
Paste this into the description and fill in what you know. Use “not yet established” for unknown scope or cause rather than guessing.
Problem: Environment: App / release / build: Browser and version: OS / device: Relevant account role or configuration: Starting state / prerequisites: Steps to reproduce: 1. 2. 3. Expected result: Actual result and exact visible message: Frequency / reproducibility: Observed impact and affected scope: Workaround and whether verified: Evidence: Screenshot / recording / diagnostic reference: Attempt timestamp and time zone: Relevant related reports: Investigation so far: Tests performed and results: Open questions: Verification criteria:
Keep the details that affect reproduction. A long inventory of unrelated hardware does not compensate for missing starting conditions or the exact failing action.
Filled Jira bug-report example
This is an illustrative report using demonstration data, not a production incident. It separates observation from the cause that still needs investigation.
Title: CSV export fails for a saved report Work type: Bug Problem: Selecting Export for a saved report shows an error and does not start a file download. Environment: Test workspace, affected app build recorded in the ticket. Chrome on Windows; exact versions included with the test evidence. Reporter has access to the saved report. Starting state: Signed in to the test workspace with a saved report containing demonstration data. Steps: 1. Open Reports and select the saved report. 2. Choose CSV as the export format. 3. Select Export. Expected: A CSV file downloads with the selected report data. Actual: The interface shows "Export failed. Please try again." No download begins. Frequency: Reproduced on three consecutive attempts in this test workspace. Impact: This report cannot be exported. Other reports and workspaces have not yet been tested. Workaround: None verified. Evidence: A short recording of the steps, exact error text, and attempt times. Verification: Repeat the steps in the affected environment after the change. Confirm the file downloads and contains the intended report data.
The title is more useful than “Export broken,” and the scope is more honest than “All exports fail.” Triage can update structured priority and ownership after assessing the evidence.
Severity and priority are different decisions
Severity describes the effect of the defect under your team’s definitions. Priority records its relative importance for action. State the observed harm, affected users or workflows, frequency, and available workaround so the triage owner can make the decision.
Atlassian documents configurable priorities, along with status and resolution fields. Do not assume another team’s “Critical” label or response target applies to yours.
| Observed situation | Information triage needs |
|---|---|
| A workflow is blocked | Which workflow, affected scope, frequency, and any verified workaround |
| Unexpected data behavior | What changed, evidence, affected scope, and the appropriate specialist owner |
| A visual defect | Whether it prevents a task or only affects appearance |
| An intermittent failure | Attempt count, conditions, timestamps, and what differs between successes and failures |
A proposed priority is useful when accompanied by its reasoning. Avoid inventing a fix deadline or presenting a severity-to-response-time matrix as a Jira requirement.
Attach evidence that answers a question
Use a screenshot for a specific visible state and a short recording for a sequence of actions. Introduce each attachment: what it shows, which attempt it belongs to, and where the important moment occurs. Keep reproduction steps in text so a reviewer can follow them without replaying the video.
Atlassian’s attachment guide covers adding files to work items. Available attachment actions depend on permissions and the site’s settings. For an external recording link, verify access from the intended reviewer’s context.
Use demonstration data where possible and review diagnostic files before attaching them. Do not include passwords, tokens, unrelated customer records, or a whole desktop when a limited view answers the question.
What if a bug field is missing or required?
Check the selected destination and work type, expand the form, and read the visible required-field messages. Some fields may be hidden or unavailable under the configuration. Give the administrator the space, work type, missing field, and action you were trying to complete.
Atlassian’s field-behavior documentation describes administrator controls for availability and required fields by work type, including a progressive rollout of field schemes. Its team-managed field guide covers that configuration separately.
A copyable description is a useful starting point. A separate mandatory field is worth adding when the team needs structured information for a real decision. Review the reporter’s workload and test the form before introducing more required fields.
Triage and verify the report
- Confirm the report. Check the expected behavior, reproduction steps, and evidence.
- Check related work. Link duplicates or related reports while preserving new information.
- Record impact and priority. Use the team’s definitions and explain the decision.
- Assign the next action. Give investigation or a request for missing details a clear owner.
- Keep the status accurate. Follow the configured workflow rather than assuming every Jira site has the same sequence.
- Verify the outcome. Repeat the relevant steps in the affected environment and record the result.
Status describes the place in the workflow; resolution records how the work was completed. A report marked duplicate or not reproducible is not the same outcome as a verified fix. Keep the result understandable for the reporter and the next support agent.
Request evidence from the support ticket
If the report begins in customer support, keep the customer recording associated with the original conversation and link the relevant moment in Jira. Screendesk can request recordings from Zendesk, Intercom, and Help Scout. Help Scout email adds the submitted URL to the ticket; chat customers need to paste it back into the conversation.
For Zendesk, a recording macro can insert a request link tied to the ticket ID. Test submission and the returned note before rolling it out. Console and network logs need supported capture setup and an eligible plan; attach only the context actually collected.
Choosing a capture tool for that workflow? Compare Screendesk and Birdie.so by helpdesk handoff, technical context, and pricing rather than by a generic feature count.
Frequently asked questions
Are expected result and reproduction steps separate Jira fields?
They can be configured separately, but they are not guaranteed fields in every form. Include them in the description when no dedicated field is available.
Is Description always mandatory for a Jira bug?
Required fields depend on configuration. A useful defect report still needs enough detail to understand and reproduce the problem, whether it appears in Description or structured fields.
What is the difference between Affects versions and Fix versions?
Affects versions identifies releases where the problem occurs. Fix versions identifies the release for the work or fix. Record confirmed values using the team’s version-management process.
Should I create a new report for every customer who sees the bug?
Check for an existing investigation first. Add new scope, conditions, or evidence through the team’s process, and link separate support cases where appropriate.
