How to Close a Bug in Jira: 6 Clear Steps to Follow Today

Unsure when a bug is truly done? Learn how to close bug in Jira in 6 clear steps, verify fixes, and prevent reopened issues. Read now.

A bug can be fixed and still sit open in Jira, leaving your team unsure whether anyone should act on it. Closing it too early creates the opposite problem: a defect may return, while the issue looks finished.

That uncertainty can slow releases and make bug reports harder to trust. It often comes down to unclear workflow statuses, missing verification, or a resolution field that was never set.

Here’s a reliable way to close a bug in Jira: confirm the fix, check the issue details, move it through the correct workflow transition, and verify its final status. I’ll walk you through six practical steps, plus what to do when Jira’s buttons or statuses look different.

How to Close a Bug in Jira: Six Clear Steps

To close a bug in Jira, open the issue, confirm the fix, update key details, apply the correct workflow transition, set its resolution if needed, and check that the final status is correct. The exact button labels depend on your Jira version and team workflow.

Open the bug and review its current status. Check the issue key, summary, assignee, and status so you know you are changing the right bug. Look for existing comments or linked work that could affect the next step.
Confirm the fix is ready to verify. Check the fix version, related pull request or change, and any testing notes your team uses. If the bug needs a tester or product owner to confirm the behavior, leave it open or move it to the appropriate review status.
Reproduce the original problem or run the relevant test. Follow the steps in the bug report in the affected environment. Confirm the behavior is corrected, and check nearby functionality when a change could have side effects.
Update the issue details. Add a concise comment describing what you checked and the result. Fill in required fields, such as fix version or resolution, if your workflow asks for them.
Use the correct workflow transition. Select the available action that matches your team’s process, such as Resolve, Done, or Close. If Jira presents a transition screen, complete its required fields before submitting.
Verify the final state. Check that the issue moved to the intended status and that its resolution reflects the outcome. Reopen it or contact a Jira administrator if the wrong transition was applied.

But here's the truth: clicking a button labeled “Close” is not always enough. A Jira workflow can separate the issue’s status from its resolution, so check both before moving on.

Jira product screenshot

Understand Jira Status and Resolution

A status tells you where a bug sits in the workflow, such as Open, In Progress, or Done. A resolution records the outcome, such as Fixed, Won’t Fix, or Duplicate.

Here’s why that distinction matters: an issue may appear finished while its resolution remains empty. In some Jira workflows, a transition sets the resolution automatically. In others, a required transition field or administrator-configured rule controls it.

For example, imagine a bug that your team fixed and verified in version 4.8. The status may become Done, while the resolution should show Fixed. If the issue is a duplicate, closing it as fixed would misrepresent what happened.

If the status and resolution do not match, avoid changing fields at random. Check your team’s workflow guidance or ask a Jira administrator which transition should set the correct outcome.

Check the Bug Before You Close It

Before changing the status, make sure the issue describes a problem that has actually been addressed. A clear bug report should give you enough detail to identify the affected behavior and confirm the result after a fix.

Review the steps to reproduce the original issue.
Confirm the affected product area, environment, and version.
Check that the fix or workaround is available to the people who need it.
Run the relevant test, or ask the assigned tester to confirm the result.
Look for related bugs or linked work that may still be unresolved.

Suppose a checkout bug occurred only on mobile browsers. A desktop retest alone may not confirm that the reported problem is fixed. Verify the affected scenario, then record what you tested in a short comment.

The best part? A few specific verification notes can prevent someone from reopening the same issue simply because its outcome is unclear.

Choose the Right Closure Outcome

Jira teams may use different resolution options. The right choice describes what happened to the bug, rather than simply marking every completed issue as fixed.

Fixed: The defect was corrected and the change passed the required checks.
Duplicate: Another issue already tracks the same problem. Link the related issue so the team can find it.
Won’t Fix: The team decided not to make the change. Add a brief explanation so the decision is clear later.
Cannot Reproduce: The team could not recreate the reported behavior after reasonable checks. Note the environment and steps tested.
Works as Designed: The observed behavior matches the product’s intended behavior. Explain the expected result to reduce confusion.

Some Jira projects use different labels or restrict which outcomes are available. For instance, a team may use Rejected instead of Won’t Fix. Follow the choices offered in your project and ask your administrator when the intended outcome is missing.

What to Do When Jira Won’t Let You Close a Bug

A missing transition button usually points to a workflow, permission, or required-field issue. The cause may be specific to the project, issue type, or current status.

No close or resolve action appears: Check whether another transition is available, such as moving the issue to Ready for QA. Your role may not have permission to complete the final transition.
Jira reports a required field: Read the prompt and complete the missing field, such as resolution, fix version, or a review note. Then retry the transition.
The issue changes back to an open status: Review recent automation activity or workflow rules. A rule may reopen issues when a linked change, test, or release condition is unmet.
The resolution field is unavailable: Your workflow may set it during a transition, or your permissions may not allow direct edits. Use the correct transition instead of trying to bypass the workflow.

Let me explain: Jira is configurable, so the same issue can behave differently across projects. If the available actions do not match your team’s process, share the issue key and the exact message with your Jira administrator.

Keep Bug Closure Useful for the Whole Team

A good closure gives the next person enough context to understand the outcome without repeating your investigation. Keep the final comment short, specific, and tied to the original report.

For example: “Verified on Android 14 using version 4.8. The checkout button now submits the order, and the related regression test passed.” This tells a teammate what you checked and where.

When you close a duplicate, link the issue that will remain active. When a bug cannot be reproduced, list the environment and steps you tried. These details make the issue history more useful during support, release reviews, and future investigations.

You might be wondering: should every bug get a long closing note? No. A short note is enough when the outcome is obvious, but add detail when the fix, test conditions, or decision could be unclear later.

Bug-Tracking Workflow Alternative: ONES.com

ONES.com brings project management and knowledge management together, with ONES Project for work tracking and ONES Wiki for team knowledge. ONES Project is a Jira alternative for teams that want customizable workflows, reporting, and deployment options; ONES Project and ONES Wiki are sold separately.

ONES.com product screenshot

If your team is refining how it tracks and closes bugs, the issue workflow should make ownership, verification, and outcomes easy to see. Here are ways ONES Project can support that process:

When teams lose time to inconsistent statuses: Configure custom workflows around review, testing, and closure. The result is a clearer path from reported defect to verified outcome.
When issue fields do not fit your process: Add custom fields for affected versions, test environments, or closure reasons. This helps teams capture useful context at the right step.
When sprint work and bug work compete: Use sprint management to plan defects alongside other work. Teams can see what is committed and what remains open.
When progress is hard to track: Use built-in reporting to review issue status and work patterns. This makes it easier to spot a backlog of bugs awaiting verification.
When repeated handoffs need reminders: Set up automation for routine workflow actions. The team can reduce manual follow-ups while keeping its own approval rules in view.
When Jira-compatible workflows matter: Use familiar workflow approaches while adapting fields and transitions to your team. This can make process changes easier to manage.
When plugin reliance adds complexity: Use native project features for workflows, fields, sprint management, automation, and reporting. That may reduce the need to assemble a process from multiple plugins.
When deployment control is important: Choose Cloud, On-Premise, Private Cloud, or Air-gapped deployment. ONES states that its cloud and self-hosted versions have full feature parity.

Application scenarios: A software team can create a bug path from Open to In Progress, Ready for QA, and Done, with a required verification note before closure. A team in a restricted network can use an air-gapped deployment while keeping the same core capabilities as the cloud version.

ONES.com offers a free plan for up to 30 seats. Teams can assess whether ONES Project fits their workflow before deciding how to deploy it; ONES Wiki is a separate product for knowledge management.

Common Challenges When Closing Jira Bugs

The Bug Is Marked Done, but It Still Appears Open in Reports

Problem: The issue’s status may be complete while its resolution is empty or set incorrectly. Some reports distinguish between status and resolution.

Solution: Review the issue’s resolution and use the workflow transition that sets the intended outcome. If the field cannot be changed, ask a Jira administrator to check the project’s workflow configuration.

A Teammate Reopens the Same Bug

Problem: The closing comment may not explain what was tested, or the original failure may still occur in a different environment.

Solution: Add the exact environment and scenario you verified. If the problem persists, reopen the issue with updated reproduction steps rather than creating a second report.

The Wrong Resolution Was Selected

Problem: A duplicate or rejected bug may have been marked as fixed, making reports and release reviews less accurate.

Solution: Correct the resolution if your permissions allow it, or ask an administrator to adjust the issue. Add a short comment explaining the correction.

The Bug Cannot Be Closed Without a Required Field

Problem: Jira blocks the transition because a required field is blank, such as fix version or a closure reason.

Solution: Complete the requested field with an accurate value. If the prompt is unclear or the field does not apply, ask your project administrator how the workflow should handle it.

FAQs

What is the difference between resolving and closing a Jira bug?

Jira teams configure these terms differently. In some workflows, Resolve marks the work complete while leaving room for verification or review. A later Close transition may represent the final state. Check your project’s workflow and resolution field rather than assuming the labels mean the same thing everywhere.

Can I close a Jira bug without setting a resolution?

Sometimes a workflow sets the resolution automatically during a transition. In other projects, Jira may require a resolution before the issue can reach its final status. If the issue looks finished but reports still treat it as unresolved, check whether its resolution is empty and ask an administrator about the configured transition.

Should I close a bug if I cannot reproduce it?

Close it as Cannot Reproduce only when that outcome is available and your team’s process allows it. First, retry the reported steps in a relevant environment and note what you checked. If the issue may depend on missing details, ask the reporter for clarification or move it to a waiting status instead of closing it prematurely.

How do I reopen a bug after closing it?

Open the issue and look for a transition such as Reopen or Reopened. If it is unavailable, your permissions or workflow may prevent direct reopening. Ask a project administrator for help, and add a comment explaining what failed and how the problem was reproduced again.

Conclusion

To close a Jira bug reliably, verify the fix, update the issue, use the right workflow transition, and check both the final status and resolution. The process may vary by project, so follow the actions your team has configured.

A clear closing note can save your teammates from repeating a test or reopening an issue without context. When Jira’s workflow blocks the transition, check required fields and permissions before asking an administrator to review the setup.

With these six steps, you can close bugs with a clear outcome and a useful trail for the next person who needs to understand what happened.