If you manage Atlassian products for a growing organization, there is a good chance you have inactive accounts quietly consuming license seats. Jira Cloud has no built-in way to automatically deactivate users based on inactivity -- leaving the cleanup burden entirely on admins. This guide covers every practical method to deactivate inactive Jira users automatically, from manual admin steps to REST API scripting to Marketplace automation.
Why Jira Doesn't Deactivate Inactive Users Automatically
If you've ever audited your Atlassian organization and found dozens of accounts that haven't logged in for six months, you're not alone. One of the most common admin frustrations is the need to deactivate inactive Jira users automatically — yet Jira Cloud has no built-in mechanism to do so based on inactivity. Every dormant account quietly consumes a license seat until an admin manually tracks it down and removes it.
For small teams this is manageable. For organizations with hundreds or thousands of users, it becomes a real cost and security problem. Research suggests that 10–20% of licensed Atlassian users are inactive at any given time — a meaningful chunk of your annual bill going to accounts that nobody is using.
This guide walks through every practical method for cleaning up inactive Jira users, from manual admin steps to REST API scripting to Marketplace automation, along with how to handle the edge cases that trip most teams up.
Why Atlassian Doesn't Offer Native Auto-Deactivation
Atlassian's position has been that automated deactivation carries risk — a user inactive for 91 days might need access on day 92, and an unexpected deactivation mid-sprint can disrupt project workflows. As of early 2026, the feature request for automated inactivity-based deactivation remains open with "Gathering Interest" status on the Atlassian feedback tracker.
The gap is real and well-documented. The official Atlassian support article on bulk user deactivation acknowledges outright: "Currently, you can't automate the removal of inactive users directly through the Jira User Interface." Their recommended alternatives are manual admin actions, REST API scripting, or third-party Marketplace apps.
That's not necessarily a failing on Atlassian's part — the reasons for a user's inactivity vary widely. But it does mean the burden of user lifecycle management falls entirely on you.
Method 1: Manual Deactivation via Atlassian Admin
The simplest approach to bulk deactivate Jira users requires no technical setup, but it doesn't scale well beyond a handful of users.
Steps for Jira Cloud
- Go to admin.atlassian.com and navigate to your organization.
- Select User management and filter for users by last login date.
- Identify accounts inactive beyond your threshold (commonly 30, 60, or 90 days).
- For bulk removal from product access: go to Settings > User Management > Groups, open the default Jira Software group, select the inactive users, and remove them from the group. This revokes their product license without deleting their account.
- To fully deactivate an account, click into the user's profile and select Deactivate account.
The key distinction here: removing a user from a product group revokes their license seat but leaves the account active. Deactivating the account blocks them from logging into Atlassian entirely. For most teams, revoking product access while keeping the account is the safer default — it preserves historical data associations and makes reactivation straightforward if the person returns.
Method 2: REST API Scripting
For teams comfortable with scripting, the Atlassian User Management REST API provides programmatic control over account lifecycle. This is the fastest path to bulk deactivation without purchasing additional tools.
Deactivating a User via API
The lifecycle disable endpoint accepts a POST request with the user's account ID:
curl --request POST \
--url 'https://api.atlassian.com/users/{account_id}/manage/lifecycle/disable' \
--header 'Authorization: Bearer <access_token>' \
--header 'Content-Type: application/json' \
--data '{"message": "Account deactivated due to inactivity"}'To do this at scale, you would:
- Export a list of users with their last login timestamps (available via the Jira Cloud REST API v3 or from admin.atlassian.com exports).
- Filter for accounts inactive beyond your threshold.
- Loop through the list and call the disable endpoint for each account ID.
Limitations to Know
The API approach has meaningful constraints. First, it only works for managed accounts — users whose email domain has been claimed by your Atlassian organization. Unmanaged accounts (personal Atlassian accounts added directly to your site) cannot be deactivated via this API; they can only be removed from product groups. Second, if your organization uses SCIM provisioning through an IdP like Okta or Azure AD, deactivation should happen at the IdP level — using the API directly can conflict with SCIM sync and create inconsistent states. Third, this requires ongoing script maintenance and doesn't run automatically without a scheduled job (e.g., a cron job or a CI/CD pipeline trigger).
Method 3: Marketplace App Automation
For teams that want ongoing, policy-driven Jira user cleanup automation without writing and maintaining scripts, Marketplace apps are the practical choice. Several options exist on the Atlassian Marketplace that address user lifecycle management with varying feature sets.
One option is User Management Automation – For Jira & Confluence by Seats Management. It's built on Atlassian Forge, which means it runs natively inside the Atlassian platform — no external servers, no data leaving your Atlassian environment. The app covers both Jira and Confluence in a single install, handles unmanaged accounts (which the REST API cannot touch), and is fully compatible with SCIM provisioning environments. You configure an inactivity threshold, set which groups to monitor, and the app handles recurring cleanup automatically. It also maintains audit logs of all deactivation actions, which is useful for compliance reporting.
ScriptRunner is another option for teams already using it — it allows custom Groovy scripts to be scheduled for user management tasks, though it requires scripting expertise and ongoing maintenance.
When evaluating Marketplace apps for this use case, the key questions to ask are: Does it handle both managed and unmanaged accounts? Does it work alongside your SCIM configuration without creating conflicts? Does it cover Confluence as well as Jira, or does it require separate installs?
Handling Edge Cases
Automated deactivation is straightforward in theory, but real organizations have complexity that simple "inactive for X days" rules can't always anticipate.
Users on Extended Leave
Employees on parental leave, sabbatical, or medical leave will appear inactive but should not lose their access. The standard mitigation is to maintain a protected group — a group exempted from automated deactivation — and add users to it before their leave begins. Any tool or script you use should support a "skip groups" or exclusion list feature.
Unmanaged Accounts
Unmanaged accounts are Atlassian accounts where you haven't claimed the email domain — typically contractors or external collaborators using personal email addresses. You cannot deactivate these via the standard API, but you can remove them from product groups to revoke license access. Purpose-built apps that handle unmanaged accounts fill this gap for teams with significant contractor populations.
SCIM-Provisioned Users
If you provision users through an IdP using SCIM, deactivation should flow from the IdP — not from Jira directly. Deactivating at the Atlassian level for a SCIM-synced user can create sync conflicts on the next directory sync. The clean approach is to manage the inactive flag in your IdP and let it propagate. If you're using a Marketplace app, verify it respects SCIM-managed accounts and doesn't create conflicting deactivation states.
Users Who Never Logged In
Onboarding processes often provision access well before a new employee actually logs in. Accounts that were created but never used are straightforward to identify — their last login timestamp is null — and are safe candidates for removal from product groups after a reasonable onboarding window (commonly 14–30 days). Treating "never logged in" accounts separately from "was active but went inactive" accounts allows for more targeted cleanup.
Building a Sustainable User Cleanup Process
Whichever method you choose, the goal is to move from reactive, one-off audits to a consistent, repeatable process. A few principles that apply regardless of tooling:
- Deactivate, don't delete. Deleting a Jira user is permanent and removes their historical associations with issues, comments, and workflows. Deactivating or revoking product access preserves the history while freeing the license. Reserve deletion for accounts confirmed to be permanently departed with no relevant history.
- Set a threshold that fits your organization. Ninety days is a common starting point, but teams with seasonal usage patterns or long project cycles may need longer thresholds to avoid false positives.
- Establish a protected exclusion list. Admin accounts, service accounts, and users on leave should never be subject to automated deactivation. Maintain this list and update it proactively.
- Keep an audit trail. Whether you're using an API script that logs to a file or an app with built-in audit logs, you need a record of what was deactivated and when — both for compliance and for resolving "why can't I log in?" support tickets quickly.
- Review quarterly. Even with automation in place, a human review of deactivation activity on a quarterly basis catches edge cases and helps refine your thresholds over time.
Next Steps
If you're managing fewer than 50 users, the manual admin approach through admin.atlassian.com may be sufficient if you run it consistently. For larger organizations or teams that want truly hands-off automation, the REST API (with a scheduled runner) or a Marketplace app are the practical paths.
Start by running a one-time audit: export your user list with last login timestamps, identify accounts inactive for 90+ days, and understand how many fall into managed vs. unmanaged categories. That baseline will tell you how big the problem is and which cleanup method makes sense for your organization's scale and technical capacity.
Keeping your Jira user list clean isn't just about license costs — it's a security practice. Every dormant account is a credential that could be compromised without anyone noticing. A consistent deactivation policy closes that surface and keeps your Atlassian environment accurate and auditable.