Updated

Use Case

Bug & Issue Tracking

A bug isn't a task with a red label — it needs its own fields, its own severity, and its own status pipeline. Every project has one built in, so a small team never has to run two tools.

Product Preview
Screenshot of bug & issue tracking in the app
/images/use-cases/bug-and-issue-tracking.jpg

How to Do This in My First Task

01

Log the bug with real detail

Title, severity (critical/high/medium/low), environment, steps to reproduce, and expected vs. actual results — captured once, correctly.

02

Move it through a status pipeline built for QA

Open → In Progress → Fixed → Retest → Verified — a status model that matches how bugs actually get resolved, not a generic to-do/done.

03

Link it to the task that fixes it

Optionally connect the issue to the task where the fix is being built, so the bug report and the work stay linked.

04

Track severity across the whole workspace

Reports break down open issues by severity and status, so a spike in critical bugs is visible before it's a fire drill.

Why It Matters

QA and engineering share one source of truth instead of a spreadsheet handoff
Severity is a structured field, not a guess based on a task's title
Small teams avoid the overhead of running a task manager and a separate bug tracker
Every issue is scoped to its project, so bug volume doesn't clutter unrelated work

Frequently Asked Questions

Do I need a separate Jira instance to track bugs?

No — every project's issue tracker is built in and included on every plan, including Free.

Can I report a bug without knowing which task will fix it?

Yes — an issue doesn't require a linked task. Connect one later once you've decided how it'll be resolved.

Can external testers or QA-only teammates log issues?

Yes — invite them with a Member role scoped to the relevant workspace, so they can create and comment on issues.