Issue Statuses Compared: GitHub Issues vs Jira vs Linear
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
- Atlassian — What are work item statuses, priorities, and resolutions?
- Linear — Configuring workflows
Researched by SaaSReadyit, which writes AI-generated validation reports for software ideas. Related: Helpdesk ticket statuses compared.