Confluence licensing is one of those costs that grows silently. Unlike Jira, where usage patterns are tied to daily sprint work, Confluence access tends to be broader and less frequently audited. The result: a significant number of licensed Confluence users who haven't logged in for months, each quietly consuming a paid seat.
This guide covers how to identify inactive Confluence users, what your options are for removing or deactivating them, and how to build a sustainable cleanup process -- whether manual or automated.
Why Confluence Inactive Users Are Easy to Miss
Most Atlassian admins focus their user management efforts on Jira. That makes sense -- Jira is typically the more expensive product and the one with more active daily users. But Confluence licenses are billed separately, and the inactive user problem is often worse there for a few reasons:
- Broader provisioning: Many organizations give Confluence access to everyone by default, including people who rarely use it. New hires get added to the confluence-users group as part of onboarding, regardless of whether their role requires it.
- Less frequent usage patterns: Some Confluence users only log in for quarterly planning, annual reviews, or onboarding documentation. A 90-day inactivity threshold might flag legitimate users more often than in Jira.
- Separate admin visibility: Confluence user management is separate from Jira's. An admin who diligently cleans up Jira users may not think to check Confluence at the same time.
The cost impact is real. At Atlassian's Standard tier pricing (~$5.75/user/month for Confluence), 20 inactive users represent roughly $1,380 per year in wasted spend. For organizations with hundreds of Confluence users, the number grows quickly.
How to Identify Inactive Confluence Users
Method 1: Atlassian Admin Export
The simplest approach is to export your user list from admin.atlassian.com:
- Go to admin.atlassian.com and select your organization
- Navigate to User management
- Filter for users with Confluence product access
- Sort or export by last active date
- Flag anyone inactive beyond your threshold (60, 90, or 120 days is common for Confluence)
This gives you a snapshot, but it requires manual effort each time and doesn't distinguish between Confluence-specific activity and general Atlassian login activity.
Method 2: Confluence REST API
For teams comfortable with scripting, the Confluence Cloud REST API can help identify users programmatically. You can query user groups and cross-reference with the Atlassian Admin API's last-login data to build a list of users who have Confluence access but haven't used it recently.
The limitation: the Confluence API itself doesn't expose per-user last-activity timestamps directly. You need to combine it with the organization-level user management API, which tracks last login at the Atlassian account level rather than per-product.
Method 3: Marketplace Apps
Several Marketplace apps provide user activity reporting and automated cleanup for Confluence. The advantage of purpose-built tools is that they can track Confluence-specific activity (page views, edits, comments) rather than just login timestamps, giving you a more accurate picture of who is actually using the product.
User Management Automation for Jira & Confluence is one option that handles both products in a single install. Full disclosure -- I work on this app. It monitors user activity across both Jira and Confluence independently, so you can set different inactivity thresholds for each product and clean up users who are inactive in one but active in the other.
Removal Options: Deactivate vs. Remove from Group vs. Delete
Once you have identified inactive Confluence users, you have three main options:
Remove from Confluence Product Group
This is the safest and most common approach. Remove the user from the confluence-users group (or whichever group grants Confluence product access). The user loses their Confluence license but keeps their Atlassian account. Their historical content (pages, comments, contributions) is preserved. Reactivation is as simple as adding them back to the group.
Deactivate the Atlassian Account
This blocks the user from logging into any Atlassian product, not just Confluence. Use this when the person has left the organization entirely. It frees up licenses across all products simultaneously.
Delete the Account
Permanent and irreversible. Deleting removes the user's association with their historical content. Generally not recommended unless required by data retention policies (e.g., GDPR right to erasure requests). In most cases, deactivation is the better choice.
Handling Edge Cases
Users Active in Jira but Inactive in Confluence
This is the most common edge case. A developer who uses Jira daily but never opens Confluence is still consuming a Confluence license if they are in the confluence-users group. These users are safe to remove from Confluence access -- they can always be re-added if their role changes.
Infrequent but Legitimate Confluence Users
Some roles only use Confluence quarterly (HR for policy updates, finance for quarterly reports). A 90-day threshold would incorrectly flag these users. Consider either a longer threshold for Confluence (120-180 days) or maintaining an exclusion list for known infrequent-but-legitimate users.
Unmanaged Accounts
External collaborators using personal email addresses (not under your verified domain) are unmanaged accounts. These cannot be deactivated via the standard admin API -- they can only be removed from product groups. If your organization has significant external Confluence collaborators, make sure your cleanup process handles unmanaged accounts specifically.
Building a Sustainable Cleanup Process
A one-time audit gets your Confluence user list clean. Keeping it clean requires a repeatable process:
- Set a Confluence-specific inactivity threshold. This can and should be different from your Jira threshold. 90-120 days is a reasonable starting point for Confluence.
- Run the cleanup on a regular cadence. Monthly is ideal; quarterly at minimum. The longer the gap between cleanups, the more inactive users accumulate and the more you overpay.
- Notify before removing access. A 7-14 day warning email gives users a chance to log in if they still need access, reducing false positives and support tickets.
- Keep an audit trail. Document who was removed, when, and why. This is essential for compliance (SOC 2, ISO 27001) and for quickly resolving "why can't I access Confluence?" support requests.
- Consider automating. Manual monthly audits work for small teams. For organizations with 100+ Confluence users, automation tools pay for themselves within weeks by ensuring continuous cleanup without admin effort.
The Bottom Line
Confluence inactive user management is often the forgotten sibling of Jira license optimization. But the cost savings are just as real, and the cleanup process is nearly identical. If you have already built a Jira user cleanup process, extending it to Confluence is straightforward. If you have not started either, Confluence is often the easier place to begin because the usage patterns are clearer and the false-positive risk is lower.
Start with an export from admin.atlassian.com, identify users inactive for 90+ days, and remove their Confluence product access. That first audit will likely surface meaningful savings -- and give you a clear picture of how much ongoing automation is worth for your organization.