Issue tracking software: how to pick one for a small team

An issue tracker is a shared list of work items. Each item is a bug, a task, or a request, and each one has a status, an owner, and a history. For a small team, the right tracker is the one people update. Start with the tracker built into the place your code already lives. Move when that list hurts: when people outside the repo cannot file a bug, or when the statuses no longer match the work.

Picking a tracker is this page. The states a bug moves through after it is filed are the software bug life cycle. The block to paste into the ticket is the bug report template.

What counts as an issue

An issue is one piece of work someone can finish or explicitly decline. Four kinds cover a small team's list.

• Bug. The product did something it should not have, or did not do something it should have. The ticket needs steps and evidence, or it sits in new.
• Task. A change that is not a defect: a migration, a dependency bump, a rename.
• Feature request. A behavior someone wants that the product does not claim yet. It is not a bug unless you had already promised it.
• Support escalation. A customer report that engineering has to answer. It becomes a bug only after someone can reproduce it.

Write one of those four on the ticket. A ticket that is a bug and a feature and a question will not get a status anyone trusts.

Issue tracking, bug tracking, and project management

Bug tracking is the narrow list. The life cycle on a single defect, from new to closed, is the software bug life cycle. Issue tracking is that list plus everything else the team has agreed to do. Project management adds schedule and coordination. A small team often does all three in one tool until the schedule needs its own view. Adding a second tool before the first list is current gives you two stale lists.

What matters for a small team

Skip the features you will not configure. These are the ones you will notice in the first month.

• Statuses you will actually move. New, in progress, done, and won't do is enough. A workflow with twelve columns and required fields on every transition is how tickets stay in the first column.
• An assignee. One person owes the next action. A team name is not an assignee.
• Labels. Bug versus task, and the area of the product. Labels are how you filter. They are not a second title.
• Links to commits and pull requests. The fix should point at the change, and the change should point at the ticket. This is the main reason to start in GitHub or GitLab if that is where review happens.
• Search. You will file the same bug twice unless you can find the first one.
• An API or a way to create tickets from somewhere else. Support and the deploy pipeline should be able to open an item without a person retyping it. You do not need that on day one.
• Permissions. Someone outside the company should not see internal tasks. A private repo's issue list already does this. A separate tool needs the setting checked.

Leave custom fields, time estimates, and portfolio views until a real report needs them. Each field you require is a field people skip, or a reason they do not file.

Common options

This is not a ranking. Prices change. Check the vendor's pricing page before you compare bills. The fit below is about where the work already happens.

GitHub Issues. Use it when the code, the review, and the people who fix bugs are already on GitHub. Issues sit next to pull requests, and a commit message can close one. People without repository access cannot file there unless you invite them. That is the usual reason a team outgrows it.

GitLab Issues. The same shape, for code that lives on GitLab. Issues, merge requests, and the repository are one project. The same access limit applies: the people who can file are the people who can see the project, unless you open it up.

Linear. A separate tracker aimed at product engineering. Issues have a status, an assignee, and a link back to GitHub or GitLab when you connect them. It suits a team that wants a fast list and is willing to keep that list in a second app. Check current pricing. A free tier exists only if Linear's page still says so when you look.

Jira. Configurable workflows, and the tool many larger or process-heavy teams already use. A small team can run it with a short workflow. The setup cost shows up when someone has to administer schemes, screens, and permissions before a bug can be filed. Check current pricing. Do not adopt a workflow you copied from a company of a different size.

A shared document or a spreadsheet. Reasonable when one person can see the whole list and almost nobody else files bugs. It fails when two people edit the same row, or when you cannot tell who owns an item and whether it shipped. Move to the tracker next to the code at that point. Do not wait for a formal rollout.

How to choose

Run the candidate for two weeks on real bugs. A demo dataset will not show you whether people update the status.

Ask these before the trial, and answer them from the trial rather than from the marketing page.

• Where does code review happen? If it happens on GitHub, start with GitHub Issues. Every extra app is a place the status gets stale.
• Who files bugs? Engineers only, or support and customers too? Customers need a form or an email path. They should not need a repository account.
• Do people who do not write code need to read the list? A designer or a founder who cannot see the repo will not use a tracker that lives only there.
• What is the smallest status set we will keep current? If the trial produces tickets stuck in "new" with no owner, the tool is not the problem. The list has no triage.
• What did we fail to update? At the end of two weeks, count the bugs that were fixed in a pull request and never moved on the board. That number is the cost of this tracker.

A two-week trial on the bugs you are already fixing is enough. A spreadsheet of features is not.

Good issues start with a report someone can run

The assignee's first job is to reproduce the failure. A bug ticket that supports that has the steps in order, what should have happened, what happened, and the environment: URL, browser, and whether the account was signed in. It also has evidence from the failure itself: a screenshot, the console text, and the failed request's method, URL, and status.

Paste those fields from the bug report template. The longer explanation of each field is how to write bug reports. A tracker with empty descriptions is a list of titles. Search can find the title. Nobody can fix from it.

Where Monito fits

Monito is not an issue tracker. It does not file tickets in Jira, Linear, or GitHub, and it does not explore the app on its own.

It runs a browser test you write in plain English, in desktop Chromium, usually at 1440×900. The run returns Passed, Failed, or Error, with screenshots, console messages, and the network requests from that run. A run with no login also records a video. A run that signs in keeps masked screenshots instead of a recording. That evidence is what you paste into the ticket, so the report is not written from memory.

You can run it from the check command, through MCP so a coding agent can run it after a change, and in CI on GitHub Actions. Error means the check could not verify the scenario. It is not a bug to file until you have read the cause. What cannot verify means.

Safari, Firefox, and a phone are outside that run. So is production session replay of your visitors.

FAQ

When should my team start using an issue tracker?

When more than one person has to know what is in progress, or when bugs arrive from someone other than the person who will fix them. Before that, a shared document is enough. If you start, use the tracker next to the code, and keep the statuses few enough that people update them.

What is the difference between bug tracking and issue tracking?

Bug tracking is the list of defects. Issue tracking is the list of work: bugs, tasks, feature requests, and support escalations. Every bug is an issue. A feature request is an issue and is not a bug. One list lets you choose between a defect and a feature. Two lists hide that choice.

How do I convince my team to adopt a new tool?

Use it for bugs for two weeks, in the tool where code review already happens. Keep the required fields to steps, expected, actual, environment, and evidence. A tracker nobody updates is worse than the document it replaced. Adoption is the list staying current, not the feature comparison.

Run a check

Run your first test. The evidence you paste into the tracker comes from the check command.