Disclosure: I work for LeanZero, the company that built Cost Slasher, a Jira Cloud app for managing paid seats on Jira, Confluence and Jira Service Management. It went public on the Marketplace this week, so what follows is how it's designed to work and why, not results from anyone's site.
Last-active dates are a shakier signal than they look
If you look after licenses, someone has probably asked you to clear out the people who haven't been in for a while, and the obvious version is a rule: nobody seen in 30 days loses the seat. I understand the instinct, but the data under that rule is fuzzier than the report makes it look. Atlassian's documentation for user last-active dates defines active as viewing a product's page for at least 2 seconds, and says the data can be delayed by up to 24 hours. So a person who worked yesterday afternoon can still show an older date this morning. The same page says the field is empty when someone has never accessed the product, and that's a different thing from a report that couldn't load the data at all. Whatever you use, I'd read the date in Atlassian Administration again right before removing anyone, and give people a warning that runs longer than that 24-hour delay.
There's a long-running feature request for deactivation policies on managed accounts, ACCESS-720, open since 2019 and still Gathering Interest with over 200 votes, and it's one reason there are quite a few apps in this corner of the Marketplace. Then there are the people who aren't inactive at all, only away: parental leave, a sabbatical, three weeks in August. A day count can't tell them apart from someone who has left, and they find out when they come back and can't open Jira.
Planned time away
This is the part I'd look at first. A person books their time away in the app by picking the apps, a departure, a return and a time zone, previewing it and then confirming. Once a booking is confirmed, the seat they'll come back to stays reserved for them while they're away and doesn't go back into the pool for someone else. Getting their access back is scheduled to start 30 minutes before the return time they entered, so it should be back by the time they log on, and if they're back sooner there's an "I'm back early" option that uses the same reserved seat. That's a schedule and not a promise, since it still depends on them being eligible at that point, on their account and on Atlassian's side being available.
Going by the listing text of ten other apps in this category, planned leave isn't something they advertise. I can only speak for what their listings say, since I haven't been through their documentation.
A seat limit with a waiting queue
An admin sets a managed seat limit for each app. When the pool is full and someone asks for access, the request waits with an expiry recorded on it, 24 hours by default. I like this one because "we're out of seats" becomes something you can see with a time attached, which is an easier conversation to have with whoever approves the license budget. None of those ten listings mention a seat cap or a queue either.
Removing a seat only on evidence
Most of the care went into the moment a seat is taken away. Automatic release is off when you set the app up, and each app gets its own policy: Jira, Confluence and Jira Service Management agent seats each have an inactivity allowance, a warning period, restore protection after someone is given access back, and their own exclusions. A new policy starts at 30 days, a 48-hour warning and 48 hours of protection. The warning can't be set below 24 hours, which is there because of the activity delay above, and it counts from when delivery is confirmed, not from when the message was handed off for sending.
Before anyone is removed, the app checks the current policy, the account, the protection and the activity again. If the activity can't be read, the person isn't treated as inactive and isn't a candidate. A seat only counts as reclaimed once the app has verified the access is gone. For Jira Service Management agent seats, automatic inactivity release stays disabled, since there isn't reliable evidence of agent activity to base it on. You can still manage agent seats, but nobody loses one to a timer.
Two of those listings advertise deactivation after an inactivity threshold anywhere from three days to six months. That's a fair feature to offer. For me the warning and the evidence matter more than how short the threshold can go.
The way back
Inside the app, everyone has a My access page with a Check and a separate Restore for each app, and checking on its own grants nothing and reserves no seat. Someone with no seat left at all can't open the app, so there's a second route: the app generates text that an admin pastes into the access-denial message in Atlassian Administration, and that message points to a recovery page where the person signs in with Atlassian. The app doesn't save that Atlassian setting for you. The recovery page is hosted outside Atlassian, in AWS Ireland, and the sign-in asks only for the read:me identity scope with no offline access. Signing in grants nothing by itself. Other apps here also let people restore their own access, so I'm not presenting that as new. I'm mentioning it because you should know where it runs.
Where it stands
It's a beta, and the listing asks for a verified setup before you use it to manage access, with automatic release staying off until recovery, warnings, activity and capacity are checked. Setting up recovery also means requesting pairing from LeanZero. The organisation admin API key stays in Forge secret storage, while identity, the controller registry, notifications and recovery run in AWS Ireland, so it isn't a Runs on Atlassian app. The management report gives totals without individual names, and the app itself calls its savings figure a planning estimate, not proof of what's on your invoice. It's brand new on the Marketplace, so there's no track record to point to yet, and the listing screenshots come from an earlier development build.
I'm curious how you handle long leave today. Do you leave the seat alone, take it back and add the person again by hand, or exclude them from your cleanup?
