What Is the Bug Life Cycle? Every Stage, Explained

The bug life cycle (also called the defect life cycle) is the set of states a bug moves through from the moment it's reported until it's finally closed. The standard path is New → Assigned → Open/In Progress → Fixed → Retest → Verified → Closed, with side branches for bugs that get Reopened, Deferred, marked Duplicate, or Rejected. Each state exists to answer one question: whose desk is the bug on right now, and what has to happen before it moves.

What are the stages of the bug life cycle?

Most trackers implement some variation of these states. The names differ — Jira calls one "In Progress," GitHub calls it an assigned open issue — but the meaning is consistent:

1. New — the bug has just been reported and hasn't been reviewed yet. It carries a title, steps to reproduce, and ideally evidence (screenshot, console, network). Nobody owns the fix yet.
2. Assigned — a triage lead has confirmed the report is valid and handed it to a specific developer. This is where severity and priority get set, which decides how soon it's worked.
3. Open / In Progress — the assigned developer is actively investigating or writing the fix. The bug is on the developer's desk.
4. Fixed — the developer has changed the code and believes the bug is resolved, but no one else has confirmed it. "Fixed" is a claim, not a verification.
5. Retest / Pending Retest — the ball is back with QA, who re-runs the original reproduction steps against the new build.
6. Verified — QA ran the steps and the bug no longer reproduces. This is the only state that proves the fix actually works.
7. Closed — the ticket is done and no further action is expected. On healthy teams a bug reaches Closed only after Verified.

The side states: Reopened, Deferred, Duplicate, and Rejected

Not every bug walks the straight path. Four branch states handle the exceptions, and knowing them prevents tickets from silently dying:

• Reopened — the bug was marked Fixed or Closed, but it still reproduces on retest. The fix was incomplete, targeted the wrong root cause, or a later build reintroduced it. A rising reopen count is the clearest signal your fixes aren't sticking.
• Deferred — the bug is real and accepted, but the team has decided to fix it later (low priority, or blocked on other work). Deferred is a decision, not a dead end — it should carry a reason.
• Duplicate — the same defect is already tracked in another ticket. The duplicate is closed with a link to the original so the signal isn't split across two threads.
• Rejected / Not a Bug — on investigation the reported behavior is intended, a configuration issue, or unreproducible. Rejecting should always include the reason, so the reporter learns why.

Who owns each stage of the bug life cycle?

The most useful way to read the life cycle is as a chain of handoffs. The status field isn't a label describing the bug — it's a signal telling the next person the work is now theirs. Ownership shifts predictably:

• Reporter and triage lead own New and Assigned. They validate the report, deduplicate it, and set severity and priority.
• Developer owns Open through Fixed. They reproduce, find the root cause, ship the change, and hand it back.
• QA owns Retest, Verified, and Closed. The rule that prevents most quality escapes: a developer should never close their own bug. Verification is a separate pair of eyes running the exact steps.

When a bug stalls, it's almost always because a handoff didn't happen — a Fixed ticket that no one picked up for retest, or a New ticket with no evidence that triage couldn't act on.

How the life cycle maps to Jira, Linear, and GitHub Issues

The concepts are universal; the field names vary by tracker:

• Jira models the life cycle explicitly as a configurable workflow with named statuses and transition rules — you can enforce that a bug can't reach Done without passing through a QA verification status.
• Linear groups statuses into stages (Backlog, Todo, In Progress, Done, Canceled) and lets you add custom workflow states per team, so "Fixed" and "Verified" can be distinct steps before Done.
• GitHub Issues is lighter: an issue is open or closed, and the life cycle is expressed through labels (needs-triage, in-progress, needs-verification) and assignees rather than formal states.

Whichever tool you use, the discipline is the same: make the state you're in obvious, and make the next required action clear from that state alone.

How to keep bugs moving through the life cycle

1. Attach evidence at New. A report with steps, environment, screenshot, console, and network doesn't stall in triage or bounce back as "cannot reproduce." Capturing that state at report time is exactly what in-app tools like Klavity Snap automate — a right-click on the bug captures the full context so the ticket starts complete.
2. Enforce a verification gate. Don't allow Fixed → Closed directly. Route every fix through Retest so a second person confirms it against the reproduction steps.
3. Track the reopen rate. Reopened tickets are the honest measure of fix quality. If the rate climbs, the problem is usually root-cause analysis skipped in favor of symptom patching — see how to reduce your reopen rate.
4. Give every side state a reason. A Rejected, Deferred, or Duplicate ticket without an explanation erodes trust in the tracker. One sentence — "deferred to next sprint, low priority" — keeps the history usable.

Done well, the bug life cycle isn't bureaucracy — it's a shared language that tells everyone, at a glance, exactly what's happening to a defect and what has to happen next.