Jira Bug Report: Fields, Workflow and Getting Them Filed

A Jira bug report is a work item with its type set to Bug, living in a space and moving through a workflow. That much is easy. The parts that cause trouble months later are the Resolution field, which quietly decides what your reports count as fixed, and the question of who is typing all this in.

Asked how to report a bug in Jira, the mechanical answer is three clicks; the useful answer is which fields decide whether anyone can act on it. Jira is the default answer for this job at scale: 6sense estimates Jira Software holds 92.61% of the bug-and-issue-tracking market, and the 17th Annual State of Agile Report found 62% of companies using Atlassian Jira for team-level work.

How Jira models a bug

In Jira Cloud, work is represented as work items — historically called issues — that belong to spaces, historically projects, and move through a lifecycle defined by workflows. Every work item carries core fields: Project, Key, Summary, Type, Status, Priority and Resolution.

For bug tracking, four of those do the work:

The Resolution field decides what “fixed” means

This is the single most useful thing to understand about using Jira for bug tracking, and it catches teams repeatedly.

Jira treats any issue with a non-empty Resolution as resolved regardless of its Status. Jira considers the lifecycle of an issue to have ended once Resolution has a value, and issues only appear in the resolved series of reports if that field is set.

Two failure modes follow directly:

Atlassian’s own best-practice guidance is to set Resolution through a workflow post function on transitions into a Done-type status, and to clear it when reopening an issue to an in-progress or to-do status. Configure it once in the workflow rather than relying on people to remember.

Workflow, briefly

The thing that makes a bug tracking system Jira-shaped rather than a list is the workflow.

A Jira workflow is the set of statuses, transitions and rules defining how a work item moves from creation to completion. Every space needs at least one, and workflow schemes define which work types use which workflow — so a Bug can follow a different path from a Story in the same space. In company-managed projects, the workflow is also where Resolution gets set on closure.

Configuration happens in the workflow editor’s single diagram view, where statuses, transitions and rules are added and then published. Worth noting if your team still uses the older interface: Atlassian’s changelog states access to Jira’s old workflow editor is removed for all customers starting 13 July 2026, with the rollout running to 26 July 2026 across release tracks.

What to put in the report

A workable Jira bug report template keeps to fields a reporter can actually fill:

1. Summary — what breaks and where, specifically. "Checkout fails at card entry with a saved address", not "checkout broken".
2. Description — numbered steps to reproduce, expected result, actual result, with any error text quoted exactly.
3. Environment — device, operating system, browser or app version, and the build. The most commonly skipped and most frequently needed.
4. Priority — how soon, not how bad.
5. Attachment — a screenshot at minimum.

Resist adding custom fields for each of these individually. Jira Cloud enforces a hard limit of 700 fields per space from March 2026, calculated from the field configuration schemes associated with that space, and once a space exceeds that — or the 150 work types per space limit — administrators are blocked from associating additional fields or work types until usage comes down. There is no hard cap on custom fields across a whole site, but Atlassian community sizing guidance classifies a large Jira Cloud instance as having between 800 and 1,800 custom fields, and documentation notes that extensive custom field usage contributes to performance impacts on large spaces.

Getting reports in without typing them

Here is the part worth being direct about. Everything above assumes a human is filling in a form, and that is where bug quality actually degrades — the environment and build fields are the ones a person reconstructs badly, and Jira has no way to capture them for you.

There are two routes out, and they cost different things.

A tool with a built-in Jira integration. Marker.io is the clearest example: every project is configured with a name, a target website and optionally a connected integration such as Jira, so reports land as issues without anyone writing code. Its seat model matters if you are pricing it — the Starter plan at $39 a month covers 3 users, 10 projects, 10 guests and 5,000 page views, with extra users at $4 each; Team covers 15 users, 50 projects, 50 guests and 25,000 page views, with extra users at $6. Crucially, all plans provide unlimited feedback and unlimited reporters, and reporters submit through the widget without creating an account, though they can only see their own submissions and have no access to the dashboard or connected tools. It is web-only: the widget installs into website HTML via a snippet or CMS plugin.

A webhook and a receiver you write. Anything that can send an HTTP request can create a Jira issue through the API. This is the route TraceItX takes, and the trade is explicit.

What lands on that webhook is one AI-ready envelope: the annotated screenshot, console and network state, device and app context, the build, and the trail of screens and actions leading to the report. Mapping it into a Jira bug is mostly mechanical — Summary from the reporter’s title, Description from their text plus the captured steps, Environment from the device and build context, the screenshot as an attachment. The envelope is identical on web, iOS, Android and TV, so the receiver is written once regardless of how many platforms you ship.

Delivery is HMAC-SHA256 signed over the timestamp and raw body using the same scheme Stripe uses, so an existing verification helper translates directly, with retries, a stable delivery id across attempts and a dead-letter queue behind it. That matters more than it sounds when the receiver is code you own — a webhook that silently fails is worse than no integration.

What to fix first

If your Jira bug tracking is producing arguments rather than fixes, check the Resolution configuration before anything else. It is a ten-minute workflow change and it is the most common reason reporting and reality disagree.

Then look at where reports come from. A template makes a person’s job clearer; it does not make them better at remembering which build they were on. If that is the recurring gap, the fix is capture, not fields — and it is worth measuring how many of your bugs get closed as unreproducible before deciding how much that is worth.