Bug Tracking: Workflow, Priorities and Fix SLAs

Working bug tracking rests on four decisions. A separate Bug task type with required fields. A short workflow of seven statuses. Separating severity from priority. An SLA counted from bug confirmation rather than from the moment someone reported a problem. All of this can be configured in both Plane and Jira. The hard part isn’t the tool; it’s the agreements the team follows every day.

This article is for team leads, QA leads, product managers and heads of IT departments who want to get their bugs under control. Below: bug fields, statuses, a severity and priority matrix, an example SLA, intake from support and Sentry, metrics, common mistakes and a short setup outline for Plane and Jira.

The Bug task type: which fields you need

A bug shouldn’t be a regular task with a “bug” label. A separate type gives you its own set of fields, its own workflow and honest reporting. In Jira, this is the standard Bug issue type. In Plane, it’s a separate Work item type with its own properties.

Field	When it’s filled in	Why
Summary	On creation	Duplicate search and a readable list
Steps to reproduce	On creation, required	Without them, the bug isn’t taken into work
Expected and actual result	On creation	Separates a bug from a feature request
Environment and version	On creation	Browser, OS, app version, environment
Severity	On creation, refined during triage	How broken the product is
Source	On creation	Support, QA, Sentry, internal user
Priority	During triage	How quickly we fix it
Component or module	During triage	Who owns the code
Assignee and due date	During triage	Who, and by when
Fix version	On closing	Link to the release

The rule that saves the most time: a bug without steps to reproduce goes back to its author. Not “we’ll figure it out” — it goes back. After two or three weeks of this practice, the quality of bug reports improves noticeably.

Workflow: statuses from report to closure

A bug workflow is shorter than it seems. A working version:

1. New — the bug has been filed, nobody has looked at it yet.
2. Triage — the person on duty checks for duplicates, reproduces the bug, sets severity and priority.
3. Confirmed — the bug has been reproduced, priority and due date assigned. The SLA clock starts here.
4. In progress — a developer is fixing it.
5. In review — code review and QA verification on a test environment.
6. Ready for release — the fix is merged and waiting to be deployed.
7. Closed — the fix is in production.

Two final outcomes without a fix: Duplicate, with a link to the main bug, and Cannot reproduce, with a comment on what exactly was checked. A separate “Deferred” status is better replaced by a priority and a due date: a deferred bug without a date will never come back.

Handle reopening as a transition from “Closed” back to “Confirmed,” not as a new bug. Then the reopen metric is calculated automatically.

How to run triage

Triage isn’t a meeting; it’s a specific person’s responsibility. Assign a person on duty for a week, rotating among developers or QA. Their job for each new bug:

1. Look for duplicates by description and component. If one is found, close as “Duplicate” with a link.
2. Reproduce it on the reported version. If that fails, ask the author for details or close as “Cannot reproduce.”
3. Set severity and reach, and derive the priority from the matrix below.
4. Assign the component, the assignee and a due date per the SLA.
5. For P1, raise the alarm in the team channel right away, without waiting for someone to open the tracker.

For P1 and P2, triage is continuous; for the rest, one or two passes a day are enough. Once a week, the product owner reviews the decisions of the person on duty and changes priorities if needed. That way, responsibility for the decision stays with one person, and oversight with another.

Severity and priority: the matrix

Severity is a property of the bug itself. Priority is a team decision. They get confused when one field tries to answer both questions. For example, a typo on the home page has low severity but may get high priority before an ad campaign launches.

Four levels of severity:

• S1 Critical — the product or a key feature is unavailable, data or money is lost, security is compromised.
• S2 High — an important feature works incorrectly, and there is no workaround.
• S3 Medium — a feature works with an error, and there is a workaround.
• S4 Low — cosmetics, copy, inconvenience.

The triage matrix: severity in rows, reach in columns.

Severity ↓ / Reach →	All or key clients	Some users	Isolated cases
S1 Critical	P1	P1	P2
S2 High	P1	P2	P3
S3 Medium	P2	P3	P4
S4 Low	P3	P4	P4

The matrix gives a default priority. The product owner can raise or lower it, but with a comment explaining why. That keeps contested decisions visible.

Fix SLAs: example starting targets

The numbers below are an example for a product team working business hours with on-call coverage for P1. They’re a reference point for a first version, not a standard. Adjust the timelines to your product, client contracts and the actual makeup of your team.

Priority	Response (to confirmation)	Fix	Working hours	Escalation
P1	Within an hour	Same day, hotfix	24/7 on-call	Immediately to team lead and manager
P2	Within a business day	In the current sprint	Business hours	To team lead if the deadline is at risk
P3	Within two business days	In the next two sprints	Business hours	At sprint planning
P4	At the weekly triage	When possible	Business hours	Quarterly review

Three rules without which an SLA becomes decoration:

• The fix SLA is counted from the “Confirmed” status, and the response time from the “New” status.
• The due date is set during triage, manually or by automation if your tracker version supports it.
• Overdue bugs are found with a saved filter — PQL in Plane, JQL in Jira — and shown on a dashboard the team sees every day.

Jira Service Management has full SLA timers. In Plane and in standard Jira, control is built on due dates, filters and dashboards. For most product teams, that’s enough.

Intake from support and Sentry

From support

Bugs from clients come in through support, and it’s important not to let raw requests go straight into the development backlog. The setup: one inbox queue, a person on triage duty, conversion to a bug only after review.

In Plane, the inbox queue is handled by Intake: requests and email forms land in a separate stream, from which they’re accepted into a project or declined. In Jira, this role is usually played by Jira Service Management. The connection is kept with links: the bug holds the ticket number, the ticket holds a link to the bug. Support replies to the client; developers don’t correspond with clients in task comments.

From Sentry

Sentry catches errors before users do, but if you create a task for every event, the tracker will drown within a week. Rules:

• A task is created per Sentry issue, not per event.
• Automatically only after a threshold: frequency, number of affected users, a new error in a fresh release.
• Everything else is reviewed manually by the person on duty once a day.
• The task stores a link to the Sentry issue, and severity is set by a human.

Plane has a native Sentry integration. For Jira, the connection is set up via the integration on the Sentry side, Jira Automation or webhooks. Check which option is available for your version and plan.

Kazakhstan context. Many clients report problems in WhatsApp, with voice messages and screenshots, in Russian or Kazakh. Support needs a template for turning such a message into a bug with steps to reproduce, rather than forwarding it to a developer as is. The second point is personal data: screenshots from user accounts, phone numbers and IINs (individual identification numbers) in descriptions, user data in Sentry events. Mask them before filing the bug. If you can’t do without them and it matters that they’re stored in Kazakhstan, keep the tracker and error monitoring in a self-hosted environment on a server in Kazakhstan.

Bug tracking metrics

There are only a few metrics, and all of them are calculated from statuses if the workflow is set up honestly:

• Time to confirmation — from “New” to “Confirmed.” Shows whether triage works.
• Time to fix by priority — from “Confirmed” to “Closed.”
• SLA breach rate — separately for each priority.
• Reopened bug rate — a sign of rushed fixes or weak verification.
• Share of bugs from production — how many bugs were found by users and Sentry rather than QA.
• Age of the open backlog — how many bugs have been open for more than a quarter.

In Plane, metrics are collected on Dashboards from saved views; in Jira, on dashboards based on JQL. Review them as trends, weekly or once per sprint. A single number without a trend tells you nothing.

Common mistakes

• One “Priority” field instead of two. Everything becomes “high,” and priority stops meaning anything.
• Bugs live in the general backlog without a separate type. A quality report is impossible to put together.
• An SLA without a person on duty. If nobody is responsible for triage, deadlines are missed from day one.
• Auto-creating tasks from Sentry without a threshold. The tracker fills up with noise, and important errors get lost.
• A 15-status workflow. People stop moving tasks, and the statuses lie.
• Bugs are closed on merge, not on deployment. The client still sees the error, but in the tracker it’s “closed.”
• No regular cleanup. Nobody reads a backlog of hundreds of bugs older than a year. Once a quarter, they’re either re-confirmed or closed.

Setup in Plane and Jira

Element	Plane	Jira
Bug type	Work item type with its own properties	Standard Bug type and fields
Statuses	Configured per project	Workflow and workflow scheme
Inbox queue	Intake, email forms	Jira Service Management
Filters and SLA tracking	PQL, Views	JQL, filters
Automation	Automations, Runner	Jira Automation
Reporting	Dashboards	Dashboards
Release linkage	Releases, Cycles	Versions, sprints
Errors from code	Sentry integration	Integration via Sentry, Automation or webhooks

If your tracker already has rules that move tasks and notify the people on duty, it’s worth working out where a simple rule is enough and where you need a script. We cover that in Task tracker automation: rules, scripts or AI agents. And if bugs are just one of your team’s streams alongside requests and incidents, see our breakdown of a task tracker for an IT department.

How we do it

We start with a diagnostic: we look at where bugs live now, who files them, how many statuses and fields are actually used and where deadlines slip. Then we set up the Bug type, workflow, matrix and SLA with one product team, connect support and Sentry, and collect metrics for two to three weeks. Once the setup has taken hold, we roll it out to the other teams and hand the process owner a triage guideline.

How the process works and what the result includes is described on our Jira and Plane task tracker implementation page.

---

Sources. Plane: GitHub repository and pricing. Jira: Atlassian pricing and plans.

Terms in plain words

SLA (Service Level Agreement)

An agreement on timelines: how quickly the team responds to a bug and how quickly it fixes it. Here the timelines depend on priority and are counted from bug confirmation.

Workflow

The sequence of statuses a bug goes through, from 'New' to 'Closed'. People actually follow a short workflow; they stop updating a long one.

Triage

Initial review of a new bug: duplicate check, reproduction, severity and priority assessment. It's run by an assigned person on duty, not by a meeting.

Severity and priority

Severity shows how badly a bug breaks the product. Priority shows how quickly it will be fixed, given business needs. These are two separate fields and shouldn't be mixed.

Sentry

A service that automatically catches errors in a running product and collects them into a list. It often notices a problem before users write to support.

Hotfix

An urgent fix shipped separately, without waiting for a scheduled release. It's used for the most critical bugs.

Production

The live version of the product that customers use, as opposed to test environments. A bug counts as closed only when the fix has reached it.

JQL and PQL

Query languages in Jira and Plane for finding tasks by conditions. They're used to save filters, such as 'overdue bugs', and show them on a dashboard.