---
title: "Issue Statuses Compared: GitHub Issues vs Jira vs Linear"
short_title: "Issue Statuses: GitHub vs Jira vs Linear"
description: "GitHub issues are only open or closed, Jira uses status plus resolution, Linear groups statuses into fixed categories. How each records work that was dropped, not done."
date: 2026-09-24
products: GitHub Issues=https://github.com/features/issues; Jira=https://www.atlassian.com/software/jira; Linear=https://linear.app
faq: What states can a GitHub issue have?=A GitHub issue is either open or closed. When closed, a state_reason records why: completed, not_planned or duplicate, and reopened when it is opened again. || What is the difference between status and resolution in Jira?=Status is where a work item sits in its workflow. Resolution records how it was finished, such as Done, Won't do, Duplicate or Cannot reproduce. Once the Resolution field is filled in, references to the work item show its key in strikethrough. || What are Linear's default issue statuses?=Backlog, Todo, In Progress, Done and Canceled, in that order, plus a reserved Duplicate status applied automatically. Every status belongs to one of the categories Backlog, Unstarted, Started, Completed or Canceled.
---

# Issue Statuses Compared: GitHub Issues vs Jira vs Linear

<p class="meta">Researched and verified against each product's own documentation on 2026-09-24.</p>

:::tldr
**Short answer:** GitHub issues have two states, open and closed, with a reason attached when closed. Jira gives each work item a status *and* a separate resolution. Linear lets teams name statuses freely but forces every one into a fixed category. The interesting difference is how each records work that was **dropped** rather than finished.
:::

## The models side by side

| | GitHub Issues | Jira | Linear |
|---|---|---|---|
| Built-in states | `open`, `closed` | Template defaults: To Do, In Progress, Done (and more per template) | Backlog, Todo, In Progress, Done, Canceled |
| Custom statuses | No (use labels or Projects) | Yes | Yes, inside fixed categories |
| How "why it ended" is stored | `state_reason` on close | A separate **Resolution** field | The category the status belongs to |
| "We decided not to do it" | `closed` + `not_planned` | Resolution: Won't do | A status in the Canceled category |
| Duplicates | `closed` + `duplicate` | Resolution: Duplicate | Reserved, automatic Duplicate status |

## GitHub Issues: two states and a reason

GitHub's REST API documents the state of an issue as "The open or closed state of the issue. Can be one of: open, closed." That is the whole status model.

What it adds is a reason. `state_reason` is "The reason for the state change," and "can be one of: completed, not_planned, duplicate, reopened, null." Marking a duplicate also takes a `duplicate_issue_id` — "The ID of the issue to mark as the canonical duplicate when state_reason is duplicate."

So on GitHub, "Done" and "Won't fix" are the same state with different reasons. Anything more granular — In Review, Blocked — lives in labels or in GitHub Projects fields, not in the issue's state.

## Jira: status for where it is, resolution for how it ended

Jira (which now calls issues *work items* and projects *spaces* in its documentation) separates two questions that the others merge.

**Status** is position in the workflow. The defaults depend on the template; its documentation lists To Do ("The work item has been reported and is waiting for the team to action it"), In Progress ("being actively worked on at the moment by the assignee"), In Review, Done ("Work has finished on the work item") and others such as Cancelled — "Work has stopped on the work item and is considered done."

**Resolution** is how it finished. "A work item can be completed, or resolved, in many ways. A work item resolution is usually set when the status is changed." The defaults include Done ("Work has been completed on this work item"), Won't do ("This work item won't be actioned"), Duplicate and Cannot reproduce.

The resolution field has a visible effect: "Once a work item is resolved (that is, the work item’s Resolution field is filled in), references to that work item show the key in strikethrough text." That is also the classic Jira trap — a workflow that moves an item to Done without setting a resolution leaves it looking unresolved everywhere else.

## Linear: name anything, but categories are fixed

Linear's default workflow is "Backlog > Todo > In Progress > Done > Canceled." Teams can add, rename and reorder statuses — but "the categories themselves stay in a fixed order," and every status must live in one: Backlog, Unstarted, Started, Completed or Canceled.

Linear publishes its own team's setup as an example of how far that goes:

- Backlog: Icebox, Backlog
- Unstarted: Todo
- Started: In Progress, In Review, Ready to Merge
- Completed: Done
- Canceled: Canceled, Could not reproduce, Won’t Fix

Duplicates are handled by the system: "When you mark an issue as a duplicate of another, its status is automatically changed to Duplicate — this is a system-managed status that cannot be renamed or customized." There is also Triage, "an additional status category that acts as an Inbox for your team."

## The same question, three answers

Every tracker has to record the difference between *finished* and *abandoned*, because it changes every metric — throughput, cycle time, what counts as delivered.

- **GitHub** keeps one closed state and stores the difference as a reason.
- **Jira** keeps it in a second field, which is flexible and easy to forget.
- **Linear** makes it structural: Canceled is a category, so a status named "Won't Fix" can never be counted as Done.

If you are building anything with a workflow, Linear's approach is the one worth copying: let users name statuses, but make them choose which fixed category each belongs to. Your reports then stay correct whatever the statuses are called.

## Method and limits

Read from GitHub's REST API documentation for issues, Atlassian's Jira Cloud administration documentation, and Linear's workflow documentation, on 2026-09-24. Jira's default statuses vary by space template, and all three products are configurable, so a given team's setup may differ. We have no affiliation with any of the three.

## Sources

- GitHub — [REST API endpoints for issues](https://docs.github.com/en/rest/issues/issues)
- Atlassian — [What are work item statuses, priorities, and resolutions?](https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-statuses-priorities-and-resolutions/)
- Linear — [Configuring workflows](https://linear.app/docs/configuring-workflows)

---

*Researched by [SaaSReadyit](https://saasreadyit.com), which writes AI-generated validation reports for software ideas. Related: [Helpdesk ticket statuses compared](https://saasreadyit.com/blog/helpdesk-ticket-statuses-zendesk-freshdesk-help-scout.html).*