A stale Jira user is a user with low or no recent activity. A billable Jira user is a user who can access paid Jira. The overlap is important, but stale does not prove billable, and billable does not prove safe to remove.
Use this guide to decide the next review route.
Why this matters
Stale-user reports are attractive because they look objective. But activity data can miss service accounts, users who work through notifications, recently transferred team members, or people intentionally kept for compliance or operational reasons.
Billability is about product access. Safe cleanup requires both signals: inactivity to prioritize and access-path evidence to decide.
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
A cleanup spreadsheet marks 120 users as stale. After review, 80 still have Jira product access, 20 are service or admin exceptions, 15 need manager approval, and only 45 are ready for immediate access removal.
Use stale as a discovery label
A stale label should move a user into review, not directly into removal. The next question is whether that user still has Jira product access and why the access exists.
Use billable as an access label
A billable label points to paid product access. It does not say whether the user is active, legitimate, removable, external, or controlled by an identity provider.
Handle the overlap carefully
Stale and billable users are strong cleanup candidates when no owner can justify access. They still need checks for default groups, service accounts, contractors, and project-critical exceptions.
Report the categories separately
Do not collapse stale count, billable count, cleanup candidates, approved removals, and savings into one number. Keeping categories separate prevents inflated savings and unsafe pressure.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| Stale but not billable | No paid Jira product access remains | No license cleanup action; consider account hygiene separately |
| Billable but active | Business owner and current project need | Keep unless owner removes need |
| Stale and billable | Access path, account type, and owner | Prioritize for removal review |
| Stale service account | Automation, integration, or emergency role | Hold with named owner and review date |
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 stale user count as the savings number.
- Removing inactive service accounts without owner review.
- Ignoring active users with unnecessary paid access.
- Failing to explain held-out stale users.
Checklist
- Define the inactivity threshold used for stale users.
- Check whether each stale user still has Jira product access.
- Trace groups, default groups, and roles for stale-billable overlap.
- Separate service accounts and owner-approved exceptions.
- Report stale, billable, candidate, and removed counts separately.