What an Issue Tracker Should Do in 2026
By Sebastiaan Jansen · · 7 min read
An issue tracker is the record of work a team has agreed to do. Every bug, request, and follow-up in it has an owner, a state, and a definition of done. It should also take in chat, client calls, and production errors, and show whether that work finishes this cycle. A board of titles alone is a shared to-do list.
What an issue tracker should record
A teammate should be able to pick the item up a week later from:
- A title that names the outcome ("Checkout fails on expired cards").
- Type: bug, request, task, or question.
- Repro or source: steps, or a link to the message, call, or error.
- Expected and actual behaviour, for bugs.
- An owner, or an explicit unassigned state.
- A priority the team defined, at most four levels.
- A status that matches your workflow rather than the vendor's default.
- Links to the repo, the pull request, and the release.
Add a field only when a report would be wrong without it. For bugs, start from Bug Report Template: The 8 Fields Developers Actually Need. Write "done" first: a commit, a check, or a result the customer can see. If done means the assignee says so, your cycle time is a guess.
Triage, stages, and workflow rules
An issue tracking system usually breaks at the inbox. Triage, a short meeting or a bot plus a person, rejects duplicates, returns items with no repro, sets type and priority, and assigns an owner or parks the item.
Keep stages few: New, Needs info, Ready, In progress, In review, Done. Needs info has an owner, the person who has to answer. Add a stage only for a real gate, such as waiting on the client or verified in production. If a column only renames "doing it", drop it.
A bug can't reach Ready without repro. A ticket can't reach Done without a linked change or a "no code" reason. Urgent needs a person and a date. The tool blocks an illegal move and says why. Many teams start with Bug Tracking Software: How to Choose One for a Small Dev Team. Bugs are the hard case: volume, thin reports, and a need to see what slipped through.
Where the work actually arrives
Requests start in Slack, on a call, or in an error. A long form leaves them in the thread.
- A Slack mention or emoji becomes a ticket with the thread, requester, and channel.
- Meeting notes become candidate tickets that a person accepts. Notes nobody reviewed are not commitments.
- A production error becomes a bug with stack, release, and count, and dedupes against any open ticket for the same issue.
Automatic tickets teach people to ignore the tracker. Have someone accept a draft instead. Slack Ticketing System: Turning Requests Into Tracked Work covers chat. Falrow turns Slack messages, client calls, and Sentry errors into tickets, and turns meeting notes into tickets only after review. See tickets, triage, and workflow rules and Slack, Sentry, and meeting notes. Tuesday's call should be a ticket by Wednesday, source attached.
Cycles, rollover, and a roadmap you can count
A backlog with no time box keeps growing and nobody plans from it. One- or two-week cycles force a cut: each item is in, out, or unfinished. Missed work stays, drops in priority, or gets split, but it should not roll over silently. The roadmap is tickets grouped by outcome. A slide deck drifts, and the team plans from the wrong source.
A worked example
Five people, two weeks. Monday: 22 tickets are Ready, 14 get pulled in, and eight wait with one line each. Wednesday brings six drafts from calls. Triage accepts four, rejects a duplicate, and sends one back for a screenshot. The four stay out of the cycle unless something else leaves. Friday an urgent payment bug comes in, and a lower-priority Ready ticket goes back. Eleven of the 14 finish. Three roll over, and the next plan starts with them.
Flow, cycle time, and delivery forecasts
Columns show where work sits. They don't show how long it waited. If In review widens on a cumulative flow chart, review is the bottleneck.
Cycle time runs from start to done. A mean hides the tail: one ticket in five can take a month. Track the median and a high percentile, such as the 85th, separately for bugs and features. A forecast replays recent cycle times. A Monte Carlo run does that thousands of times; two thousand runs give you a date you usually beat and a date you should not promise past. If you're missing start and stop times, don't publish a date.
DORA's software delivery metrics include lead time for changes. Tracker cycle time usually includes waiting as well as the change. Measure the wait either way.
How this differs from a code host's issues
GitHub Issues and GitLab issues sit next to the code. They weaken when work arrives from sales, support, and calls, or when you need cycles and a forecast. GitHub Issues as a Bug Tracker: Strengths and Gaps covers that trade-off. Jira can model almost any workflow, which is how teams collect unnamed columns and a priority scheme. Jira Bug Tracking: Setup, Workflow and Common Mistakes describes a tighter setup. Bugzilla still suits a team whose world is bugs in a repo, and fits poorly once requests and a roadmap share the board.
Specialised work belongs in a specialised tool. When bugs, requests, and ops tasks share one team and one cycle, use a general issue tracker.
What to demand from issue tracking software
Judge project issue tracking software by the jobs below, not its feature grid.
| Job | What good looks like | Walk away if |
|---|---|---|
| Capture | Chat, calls, and errors become sourced drafts | People retype into a form |
| Triage | Needs info, merged duplicates, blocked moves | New work is already in progress |
| Types and stages | Few types; a stage only at a real gate | Forty undefined statuses |
| Cycles | A time box and reviewed rollover | The backlog is the plan |
| Roadmap | Counted from tickets | A list edited by hand |
| Flow | Cumulative flow and percentiles | One average age, or none |
| Forecast | A range from history, sample size shown | One date, no range |
| Ownership of data | An open export, or a database you host | History you cannot read |
| Permissions | Clients see theirs; the team sees the rest | One bucket, or a week to share |
File one bad bug and one good one. If the bad bug reaches Done, the rules aren't enforcing anything. Run one real cycle, rollover included. Self-hosters should ask where data lives and whether ordinary tools can back it up. Falrow runs on one SQLite database you can self-host. Hosted makes sense when you don't want to operate anything. A month of triage costs more than a month of licenses. Skip a migration that drops comments or status history.
Put it in place this month
For two cycles, freeze your statuses and delete any column you can't define in one sentence. A bug leaves New only with repro or a source link. Triage three times a week and empty New, or defer on purpose. Pull a fixed set. When urgent work comes in, other work goes out. Record start and done, and review every rollover. If the tool can't enforce repro or the fixed set, switch.
FAQ
What is the difference between a tracker and project management software?
A tracker follows one item from request to done, with its status, owner, and history. Project management software adds plans, dates, budgets, and resource loading across a program. For a single product queue, start with item history. Add cross-team plans once you have more than one queue.
Is bug tracking software the same thing?
Bug tracking is a subset: repro, severity, version, and duplicates. A general tracker also holds requests, ops work, and client follow-ups in one cycle, so the team has a single cut line. Stay with a bug tracker until non-bug work outgrows a label. After that, types and a shared workflow matter more than a separate bug database.
How many statuses should an issue tracking system have?
Five or six: new, needs info, ready, in progress, in review, and done. Add one only for a wait those columns can't show, such as client review with its own owner. Near-synonyms like "doing", "working", and "active" hide queues. With too many statuses, a new teammate can't tell where a ticket belongs.
How long should you keep issues?
Keep closed issues for as long as you ship the product. They show regressions, why a decision was made, and whether cycle time moved. Archive issues for retired products. Don't delete history to tidy the board. Hide old client work from new clients, and keep it searchable for the team that maintains the system.