Redmine’s native issue tracking model is well-suited to bug management. A bug in Redmine is not just a task with a different label it is a distinct tracker type with its own workflow, its own required fields, and its own status transitions. That separation is what makes bug tracking in Redmine reliable rather than chaotic.
In practice, the problem most teams encounter is not that Redmine cannot handle bugs. Instead, it is that they never configure the bug tracker to reflect how bugs actually move through the team. Bugs go in, sit in a generic status, accumulate comments, and eventually get closed without a clear record of what happened, who verified it, or what environment it occurred in.
This guide covers how to track bugs in Redmine properly from setting up the Bug tracker through to QA sign-off and resolution reporting.
The short answer: Redmine tracks bugs as a dedicated tracker type with configurable statuses, required fields, and role-based workflow transitions. A well-configured Bug tracker captures severity, environment, and reproduction steps at creation, routes the bug through development and QA, and closes only after verification. Combined with the Redmineflux Test Case Management Plugin, it connects bug resolution to formal QA sign-off in the same system.
In Redmine, a tracker defines the type of work an issue represents. Bug, Feature, Task, and Support are common tracker types each can have different required fields, different workflow rules, and different status transitions. That means a Bug tracker can enforce that severity is always filled in on creation, while a Task tracker does not require it.
In fact, that flexibility is what separates Redmine’s bug tracking from a generic task list. When configured correctly, every bug that enters the system carries the information needed to reproduce, fix, and verify it without relying on team discipline or comment threads to fill the gaps.
In Redmine, go to Administration → Trackers → New Tracker. Name it “Bug” and assign it to the relevant projects. Under Administration → Issue Statuses, create the status set that reflects how bugs actually move in your team.
A practical bug status model looks like this:
Not every status is mandatory for every team. However, the Verified status is the one most teams skip and its absence means bugs get closed by developers rather than confirmed by QA. That gap leads to regressions showing up in production.
Once statuses exist, configure which roles can move bugs between which statuses. Go to Administration → Workflow. Select the Bug tracker and configure transitions for each role.
A clean bug workflow looks like this:
As a result, that structure protects process quality. Specifically, a developer cannot mark a bug Verified only QA can. A reporter cannot accidentally close a bug. Each role touches only the transitions that belong to their function.
Additionally, under Administration → Workflow → Fields Permissions, you can configure which fields are required at which status transitions. For example, require the “Steps to Reproduce” field to be filled before a bug moves from New to Confirmed. That single rule eliminates most of the “I can’t reproduce this” back-and-forth.
In practice, custom fields capture the information that separates a useful bug report from a vague one. Go to Administration → Custom Fields → Issues and create fields for the Bug tracker specifically.
Recommended custom fields for bug tracking:
These fields appear on the bug creation form. Marking Severity and Environment as required fields means every bug that enters the system arrives with the context needed to triage it immediately. Consequently, developers spend less time asking for information and more time fixing.
Not everyone who reports a bug is a developer. A QA engineer, a support agent, or even a client-facing team member may need to log bugs without understanding Redmine’s full interface.
The Redmineflux Issue Template Plugin solves this by pre-filling the bug creation form with structured prompts. When a reporter opens a new Bug issue, they see fields already labelled with guidance “Describe the steps to reproduce this bug” rather than a blank text box. Furthermore, required fields enforce completion before the issue can be saved.
The result is consistent, useful bug reports from all reporters regardless of their technical background. That consistency is what makes triage fast and development productive.
Bug resolution is not complete when the fix is deployed. It is complete when QA verifies that the fix works and that the fix did not introduce a regression elsewhere. In Redmine, that verification step belongs in the same system where the bug lives not in a separate spreadsheet.
The Redmineflux Test Case Management Plugin QA workflow and test runs inside your issue tracker links test cases directly to bug issues. When a bug moves to Fixed, the associated test case activates for QA verification. The QA engineer runs the test, logs the result, and moves the bug to Verified all within Redmine.
In this way, that connection closes the loop between development and QA. It means bug resolution has a formal record: what was tested, who tested it, and when verification passed. Moreover, that record matters for release sign-off and for retrospective review of recurring defect areas.
Want to see bug tracking connected to QA sign-off in a live Redmine environment? Book a Free Demo and see the complete workflow running in 30 minutes.
Once bugs flow through a consistent workflow with structured fields, reporting becomes straightforward. Redmine’s native issue filters let you report bugs by status, severity, assignee, version, or any custom field.
Useful bug reports to run regularly:
For more advanced reporting across projects, the Redmineflux Custom Dashboard Plugin adds visual bug metrics and project-level summary views. Project managers and engineering leads get the bug data they need without manually filtering the issue list every time.
Consider a development team running two-week sprints. Before configuring the Bug tracker properly, bugs came in with varying levels of detail. Some had reproduction steps. Many did not. No one tracked severity. Whoever finished working on a bug closed it with no QA verification step.
After configuration Bug tracker with required fields, role-based workflow, QA verification status, and test case links the same team saw three changes within the first sprint. Bug reports arrived with consistent severity and environment data. Developers stopped asking for reproduction steps because the template enforced them. Regressions dropped because QA verification became a formal step before closure.
Importantly, none of those improvements came from discipline alone. They came from the system making the right behaviour the easy behaviour.
Yes. Redmine includes a Bug tracker type as part of its native issue tracking model. You can configure its workflow, required fields, and status transitions to match how your team handles bug resolution. The base bug tracking capability ships with Redmine without any additional plugins.
Go to Administration → Custom Fields → Issues and create a new list field called “Severity” with values such as Critical, High, Medium, and Low. Assign the field to the Bug tracker and mark it as required. Every bug created after that point must include a severity rating before it can be saved.
Configure the workflow so that only the QA role can move bugs from Fixed to Verified, and only the Project Manager role can move bugs from Verified to Closed. Developers cannot bypass QA sign-off because the workflow transition is not available to their role. That single configuration change enforces the verification step without relying on process discipline.
Yes, with the Redmineflux Test Case Management Plugin. Test cases link directly to bug issues. When a bug moves to Fixed, the associated test case activates for QA. The engineer runs the test, logs the result, and moves the bug to Verified all within Redmine, with a formal record of who verified it and when.
Use the Issues filter on any Redmine project. Filter by tracker = Bug, status = open (or any specific status), and add a filter for the Severity custom field. Save the filter as a named query for repeated use. For cross-project bug dashboards, the Redmineflux Custom Dashboard Plugin adds visual metrics and summary views.
Redmineflux tests and supports all plugins on Redmine 5.0.x, 5.1.x, and 6.0.x. Teams running Redmine 4.x should contact support before purchasing to confirm compatibility.
Bug tracking in Redmine works best when the Bug tracker is configured to match how bugs actually move through the team. Required fields at creation, role-based workflow transitions, QA verification as a formal step, and test case links for sign-off together, these turn Redmine’s issue tracker into a reliable bug management system rather than a shared to-do list.
