Find inactive Jira users by reviewing last activity or usage signals, then verify whether each user still has Jira product access. Inactive status is a starting point for review, not proof that access is billable or safe to remove.
Use this guide to decide the next review route.
Why this matters
Inactive-user lists are useful because they narrow the search area. They are dangerous when treated as a removal queue.
Some inactive users no longer need Jira and still cost money. Others are service accounts, recently transferred users, external collaborators, or users whose activity is not captured by the signal you are reviewing.
For this question, the useful answer should help an admin decide what to check now, which rows to hold out, and which proof should survive after the change. That is why this page stays inside a narrow operational boundary instead of becoming a general governance essay.
Review billable access before renewal cleanup
If this cleanup is tied to renewal, wasted seats, approval, or finance proof, review License Guard for Jira License Cleanup. The useful buying question is whether the team can explain why each row still costs money before removing access.
Working scenario
An admin exports users who have not logged in for 90 days. Before removing access, the admin checks which of those users still have Jira product access, whether default groups are involved, and whether any account is a service or contractor identity.
Choose an inactivity signal
Use the available Atlassian activity or last-login data, but write down the threshold and source. A 30-day report and a 180-day report answer different cleanup questions.
Join inactivity to product access
The high-value rows are inactive users who still have paid Jira access. Users without product access may be hygiene concerns, but they are not the same license cleanup problem.
Classify account types
Separate employees, contractors, external users, service accounts, automation accounts, and admins. Each type has a different owner and removal risk.
Review groups before action
Check which groups and default groups grant Jira access. Removing a user from one team group may not help if a default group or synced group still grants the app role.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| No recent login | Threshold, data source, and current product access | Prioritize for review |
| Inactive and still billable | Access path and account owner | Ask owner or remove if approved |
| Inactive service account | Automation or integration dependency | Hold with owner and next review date |
| Inactive external user | Account ownership and collaboration need | Remove or route approval to business owner |
Common mistakes
Most cleanup errors happen when an admin treats a partial signal as a complete answer. These are the failure modes to watch for on this topic:
- Using last login as the only cleanup rule.
- Mixing non-billable inactive accounts into license savings.
- Removing automation or service accounts without an owner.
- Ignoring default groups that continue to grant access.
Checklist
- Pick and document the inactivity threshold.
- Filter for users who still have Jira product access.
- Trace groups, default groups, and direct roles.
- Classify human, contractor, external, service, and admin accounts.
- Record owner approval before removal or suspension.