Review last login as a prioritization signal, not a removal rule. A missing or old login should trigger checks for Jira product access, account type, group paths, default groups, and business ownership.
Why this matters
Last-login data feels precise, but it can be incomplete for the decision admins need to make. It does not prove billability, explain group access, show service-account purpose, or confirm whether the user is safe to remove.
Over-trusting last login creates two risks: removing accounts that still matter and missing active-but-unnecessary product access.
For the query last login jira cleanup, 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.
Working scenario
A 180-day last-login report finds a user with no recent login. The owner explains the account is used for an integration. Another user logged in yesterday but only to check an old project and no longer needs paid access. Last login alone would make both calls wrong.
Document the signal source
Record where the last-login or activity data came from and what it measures. Different Atlassian screens and exports can answer different questions.
Combine with product-access checks
The cleanup value appears when last-login data is joined to current Jira product access. Old login plus no product access is not the same as old login plus billable access.
Look for false positives
Service accounts, automation users, break-glass admins, and external users may have low interactive login but legitimate purpose. Require an owner and reason before holding them out.
Look for false negatives
Recent login does not prove continued need. Users can log in once after a notification, team transfer, or old bookmark while still having unnecessary paid access.
Decision table
| Signal | What to verify | Decision or evidence |
|---|---|---|
| No login in threshold | Product access, account type, and owner | Prioritize for review, not automatic removal |
| Recent login | Current business need and team ownership | Keep only when owner confirms need |
| No login service account | Automation dependency and safer replacement options | Hold or transition with owner |
| Missing activity data | Other access and ownership signals | Do not treat unknown as safe |
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:
- Removing every user beyond the threshold.
- Ignoring active users with unnecessary product access.
- Treating missing data as proof of inactivity.
- Keeping exceptions without reason or owner.
Checklist
- Record the last-login source and threshold.
- Join last-login data to Jira product access.
- Review groups, default groups, and direct roles.
- Classify false positives such as service accounts.
- Ask owners about recent-login users with weak business need.