An issue number is a unique identifier that a project management tool assigns to each task, bug report, or piece of work

When you create a new issue in tools like Jira, GitHub, Linear, or Asana, the system automatically gives it a number — often something like #1247 or PROJ-89. That number stays with the issue for its entire life, from the moment someone reports it until the work is done and closed. It's the quickest way to refer to a specific piece of work without typing out the full title or description.

The number serves as a permanent reference point. If someone says "we need to fix issue #402," everyone on the team knows exactly which problem you're talking about. You can link to it, search for it, mention it in code commits, and track its progress without any confusion about which task you mean.

Key Takeaways

  • Every issue gets a unique number the moment it's created, and that number never changes or gets reused.
  • Issue numbers let you reference work in conversations, code commits, pull requests, and documentation without repeating the full description.
  • Different tools format numbers differently — some use just a number (#42), others add a project prefix (PROJ-42), and some combine both.
  • The number is searchable across your entire project, so you can find related work, comments, and history instantly.

How issue numbers work across different tools

GitHub uses a simple format: #1, #2, #3, and so on within each repository. If you have multiple repositories, the numbering restarts in each one. When you mention an issue in a pull request or commit message — like "fixes #156" — GitHub automatically links them together.

Jira typically adds a project key before the number, so you might see PROJ-1, PROJ-2, or BACKEND-89. This makes it clear which project the issue belongs to at a glance, which is useful when you're working across multiple projects. Linear uses a similar approach with keys like ENG-42 or DESIGN-15.

Asana and other tools sometimes use longer identifiers or let you customize how issues are numbered. The format doesn't matter as much as the consistency — whatever system your tool uses, that number becomes the standard way your team refers to that work.

Why teams use issue numbers in daily work

When a developer commits code to fix a bug, they'll write a commit message like "Resolve database timeout — fixes #892." Later, when someone reviews the code, they can click that number and see the full context of the problem, the discussion that happened, and what was decided. Without the number, that connection is lost.

Issue numbers also appear in pull requests and code reviews. A developer might say "this PR addresses #445 and #446," linking multiple pieces of work together. Teams use them in Slack messages, emails, and documentation to point to specific tasks without repeating information.

In meetings or standups, saying "we're blocked on #203" is faster and clearer than describing the problem again. Everyone can look it up in seconds if they need details. This saves time and reduces miscommunication about what work is actually being discussed.

How issue numbers help track progress and history

Every comment, status change, and update to an issue is timestamped and attached to that number. If you need to know when a bug was reported, who investigated it, what was tried, and why a decision was made, the issue number is your entry point to that entire history.

When you search for an issue number, you find not just the original report but every conversation that followed. This is especially valuable when a similar problem appears months later — you can search the old issue number and see what was already tried, what didn't work, and why.

Issue numbers also make it easy to generate reports. A manager can ask "how many issues did we close this sprint?" and the tool counts them by number. You can filter by status, assignee, or date and get a clear picture of what work was done.

The difference between issue numbers and issue titles

The issue title is the human-readable description — something like "Login button not responding on mobile" or "Update user documentation for API v3." The issue number is the permanent identifier that never changes, even if someone edits the title later.

If a title is unclear or misleading, someone can edit it to be more accurate. The number stays the same. This is important because if you've already linked to that issue in code or documentation, changing the title doesn't break anything — the number still points to the right place.

Numbering sequences and what happens when issues are deleted

Most tools assign numbers sequentially — the first issue is #1, the second is #2, and so on. When you close an issue, the number is not reused. If you delete an issue (which is rare), the number still isn't recycled. This prevents confusion where #50 might refer to two different pieces of work at different times.

Some teams archive or mark issues as "won't fix" rather than deleting them, which keeps the full history intact. The number remains a permanent record of work that was considered, even if it was never completed.

Frequently Asked Questions

Can I change an issue number after it's created?

No. Issue numbers are permanent identifiers assigned by the system. If you need to reorganize or rename work, you edit the title and description, but the number stays the same. This is by design — it ensures that any links or references to that issue remain valid.

What happens if I reference an issue number that doesn't exist?

Most tools will show an error or simply not create a link. If you mention #999 but that issue was deleted, the reference won't work. This is rare in practice because teams usually archive rather than delete issues, keeping the numbers intact.

Do issue numbers mean anything about priority or importance?

No. A low issue number like #5 is not more important than #500. The number only reflects the order in which issues were created. Priority is set separately as a field or label within the issue itself.

Can different projects share the same issue number?

It depends on the tool. GitHub issues are numbered separately per repository, so two repos can both have #1. Jira uses project keys (like PROJ-1 and BACKEND-1) to keep them distinct. Check your tool's documentation to understand how it handles numbering across projects.

Why do some issue numbers have letters in front?

Those are project keys or prefixes. A number like PROJ-42 means issue 42 in the PROJ project. This helps teams working on multiple projects quickly see which project an issue belongs to without looking at additional context.