team
A ticket arrives that says "login is broken". It gets assigned to a developer, who cannot reproduce it, who asks a question, who waits two days for an answer, who then discovers the reporter was on a staging build from last week. Nothing about that exchange required skill. It required information that was cheap to capture at the moment the bug was seen and expensive to reconstruct afterwards. Bug reporting in Jira is mostly a question of where that cost gets paid, and the teams who get it right have moved the cost to the reporter on purpose.
A bug report has one job: let somebody who was not there see the same thing happen. Everything else about it is secondary, including how it is categorised and who it is assigned to.
That framing settles most arguments about how much detail is enough. A report that takes the reporter four minutes and the developer thirty seconds is a good trade. A report that takes the reporter forty seconds and the developer two days of guessing and asking is a bad one, even though it felt faster to file.
The asymmetry is worth stating plainly because it is not obvious in the moment. The person filing the bug has the state in front of them right now. Nobody else will ever have it that cheaply again. The browser is open, the account is logged in, the error is on screen, and the sequence of clicks is still in short term memory. Ten minutes later the tab is closed and that information costs a round trip to rebuild.
This also explains why the same team can have good reports from one group and poor ones from another. Testers file good bugs because filing bugs is their job and they have been burned. Salespeople and support staff file poor ones because they are relaying something a customer said and do not have the state at all. Those two groups need different intake, not the same form with the same instructions.
Everything else on the screen is organisation. These six are the report.
A title that is a symptom with a location. Not "checkout bug" and not "urgent". The shape that works is where, then what, then under which condition: "Checkout: card form clears after a failed 3D Secure challenge on Safari". A person scanning fifty titles in triage should be able to tell duplicates apart without opening them.
The environment, stated as specific versions. Build or release number, browser and version, operating system, device, and the account or role in use. "Latest version" is not a version. A surprising share of unreproducible bugs turn out to be a reporter on a stale build or a cached asset, and that is only visible if the build is written down.
Numbered steps, starting from a known state. Step one should be something like "log in as a standard user" or "open an incognito window", not "go to the page". One action per step. Stop at the first thing that is wrong rather than continuing to the end of the scenario.
Expected and actual, as two separate lines. Merging them into one sentence is the most common way a report becomes ambiguous, because the reader cannot tell which half is the specification and which half is the observation.
Evidence. A screen recording is worth more than a screenshot for anything involving a sequence, and both are worth more than a description. For anything on the web, the console output and the failing request add more than another paragraph of prose ever will.
Frequency. Always, one time in five, or once and never again. This single field changes the entire response. A bug that happens every time is a fix. A bug that happened once is an investigation, and knowing that up front stops a developer spending an afternoon trying to make it happen again.
A checklist in a wiki page does not survive contact with a busy week. The fields get filled when the tool asks for them at the moment of filing.
Jira's own pricing page lists unlimited forms on every plan, including Free, and a form is the most direct lever available here. Instead of handing a reporter an empty description box, hand them a form with a field per item above, with the environment fields required. The reporter is answering questions rather than composing a document, which raises completion sharply and takes less of their time, not more.
Custom fields are also listed on every plan including Free, which matters for the two fields that do not exist by default in a useful shape: frequency, and severity as distinct from priority. Both work better as a small select list than as free text, because free text cannot be filtered or counted.
Automation deserves a note, because the free plan has a real budget rather than an unlimited one. Jira's pricing page lists 150 automation steps per subscription per month on Free, against 400 per user per month on Standard. That is enough for one or two useful rules, not for a web of them. The rules worth spending it on are the ones that remove a human step every single time: route new bugs into a triage queue, and flag anything that has sat in a "needs information" state for more than a few days.
The other constraint worth knowing before designing notifications is that the free plan lists 100 emails per day. A chatty rule can consume that quietly.
Teams that use one field for both end up arguing about the field instead of the bug.
Severity describes the effect on the user. Data loss, complete blockage, a workaround exists, cosmetic. It is an observation, and the reporter can set it.
Priority describes when it gets fixed. It is a decision, it belongs to whoever owns the queue, and it comes from severity combined with how often the bug happens and how many people it reaches.
Keeping them apart has a practical payoff. A cosmetic bug on the sign up page that every visitor sees can be high priority and low severity at the same time, and that combination is impossible to express in one field. It also removes the most tiring recurring conversation in bug triage, which is a reporter marking something critical because it is blocking them personally, and a lead downgrading it, and the reporter reading that as a judgement about their work.
| Field | Who sets it | What it answers | Where it lives in Jira |
|---|---|---|---|
| Severity | The reporter | How bad is the effect when it happens | A custom select field, available on every plan |
| Frequency | The reporter | How often does it happen | A custom select field |
| Priority | The queue owner | When will this be fixed | The built in priority field |
Triage then has three questions and no others: is it reproducible, is it actually a defect rather than a change request, and when. Fifteen minutes twice a week is usually enough if the reports arrive complete.
This is the part that catches small teams late, after the process is designed.
Jira's pricing page lists a limit of 10 users per site on the free plan, with user roles and permissions and free guest access both starting at Standard. For a team of five developers that is comfortable. For the same team plus two testers, a designer, a support person and an external client who all need to file bugs, the ten seats go quickly, and there is no guest tier below Standard to put the occasional reporter into.
There are two honest ways around it. One is to keep reporting outside the tracker: a form or a mailbox that a member of the team turns into a ticket during triage. This costs a few minutes a day and keeps seats free, and it has the side effect that every ticket passes through someone who knows what a good ticket looks like. The other is to accept that reporters are users and move up a tier.
What does not work is the middle option teams reach for by default, which is one shared account that several people file under. It breaks the one thing a bug report needs most, which is knowing who to go back to with a question.
| Free plan detail | What the pricing page lists |
|---|---|
| Users per site | 10 |
| File storage | 2 GB |
| Automation | 150 steps per subscription per month |
| Email notifications | 100 per day |
| User roles and permissions | From Standard |
| Free guest access | From Standard |
Those numbers were read from Atlassian's Jira pricing page on 27 September 2026. Plans change, so they are worth re-checking before a decision rests on them.
The default bug workflow is three states, and a lot of teams expand it to nine within a quarter. Most of those additions cost more than they return, because every status is a place a ticket can sit while everyone assumes somebody else is looking at it.
Two additions usually earn their place. A needs information state, which exists so that a bug with a question on it stops counting as open work, and so that the wait is visible rather than invisible. And a ready to verify state between fixed and closed, which exists so the person who reported the bug confirms the fix rather than the person who wrote it.
Atlassian's own bug tracking page describes the pattern that makes the rest of the workflow cheap to run:
Capture bugs anywhere in your software projects with Jira. Once you've identified a bug, create a work item and add all relevant details, including descriptions, severity level, screenshots, version, and more. Source: atlassian.com
One state to avoid adding is "cannot reproduce" as a closing status. Closing a ticket that way ends the conversation while leaving the bug in the product, and the reporter learns that filing bugs is pointless. Moving it to needs information with a specific question keeps it alive and puts the next action on somebody's plate.
A last note on where the conversation about a bug should live. When the discussion happens in comments on the item, the reasoning is attached to the bug forever and the next person to hit it does not start over. When it happens in a chat channel, it is gone in a day and the same investigation gets repeated. Tools differ in how closely talk sits to the work, and the comparison pages set out how each one handles it, including tools built around development workflows.
Pick the single field that is most often missing from bug reports right now, which for most teams is the build number or the browser version, and make it required at intake with a form rather than asking people to remember it. Then split severity from priority so triage stops being a negotiation. If the reporters who need to file bugs are pushing a team past the seat limit of its current plan, it is worth comparing what other tools count as a billable user, and the pricing page shows how Pinateca draws that line.
A title that names the location and the symptom, the exact build and browser or device, numbered steps starting from a known state, the expected and actual results on separate lines, evidence such as a screen recording or the failing request, and how often it happens. The frequency field is the one most often missing and the one that most changes how a developer spends their time.
Severity describes how bad the effect is when the bug happens and can be set by the reporter. Priority describes when the fix will be scheduled and belongs to whoever owns the queue, because it depends on frequency and reach as well as severity. Keeping them in separate fields lets a cosmetic bug on a high traffic page be high priority and low severity at the same time.
Largely, yes. Atlassian's pricing page lists unlimited forms, custom fields and customizable workflows on Free, which covers the intake shape. The limits that bite are 10 users per site, 150 automation steps per month and no guest access below Standard, so a team with several occasional reporters will run out of seats before it runs out of features.
Make the environment fields required at the point of filing rather than asking for them afterwards, because the reporter has that information on screen only while the bug is in front of them. Then stop closing tickets as cannot reproduce, and move them to a needs information state with one specific question instead, so the reporter learns that filling the fields in is what gets bugs fixed.
Start with three and add a status only when it changes what somebody does. A needs information state and a ready to verify state usually earn their place, because the first makes waiting visible and the second puts confirmation on the reporter rather than the person who wrote the fix. Beyond that, extra statuses mostly create places for tickets to sit unnoticed.