Jira Cloud administration · updated July 2026

How to find unused Jira Cloud apps

Jira Cloud will tell you which Marketplace apps you are paying for. It will not tell you which ones anyone is using. Here are the six methods administrators actually use, what each can genuinely prove, and where each one quietly misleads you.

Why this is hard in the first place

Your Atlassian billing screens list what is installed and what it costs. It says nothing about whether anyone has opened it since 2023.

The request for native usage analytics — ECO-470 — has been open for over four years and carries 383 votes, with 298 watchers and more than fifty linked tickets. It is still being updated. Data Center administrators had a bundled App Usage tool; Cloud has never had an equivalent.

So every method below is a workaround. Knowing which workaround proves what is the difference between a confident cancellation and an angry team.

1. Issue history — the one dated signal available on every plan

Apps act through their own Jira account, so anything an app changes on an issue is recorded in that issue's history with an author and a timestamp, exactly like a person's edit. Sample your recently updated issues, read their changelogs, and keep the entries whose author is an app account. You get a real date: this app last changed an issue on 12 March.

It works on every plan, including Free, and needs nothing switched on in advance — unlike request logging, it can tell you about the past.
It cuts one way only. Catching an app working proves it is in use. Not catching it proves nothing, because you sampled some issues rather than all of them.
Apps that only display things never appear. A report, a chart or a panel reads your data and writes nothing back, so it leaves no trace here at any point.

2. API request logs — the closest thing to real usage

Admins on Atlassian Guard Premium or Cloud Enterprise can enable third-party app API request logging in Atlassian Administration. It is not available on lower tiers. From then on you get a record of which apps are calling Jira APIs.

It only records from the moment you switch it on — it cannot tell you about last year.
An app that renders entirely in the browser and rarely calls the API can look idle while being used daily.
Audit logs are unavailable on the Free plan entirely. We confirmed this directly against a Free-plan site: the API returns "Audit logs aren't available for this site as all of its Jira Cloud products are on Free plans."

Proves: an app is active. Cannot prove an app is inactive.

3. Configuration footprint — the most reliable signal

Most substantial apps leave traces in your configuration: custom fields, dashboard gadgets, workflow post-functions, conditions and validators. Each of those records the key of the app that created it. Walk your configuration, attribute every element to its owning app, and anything with no footprint anywhere becomes your first removal candidate.

You can do the custom-field part manually in about a minute. Open https://YOUR-SITE.atlassian.net/rest/api/3/field/search?maxResults=200 while signed in as an admin. Use /field/search, not /field — the latter returned 9 fields on a site where the former returned 90, omitting every third-party field. Every custom field carries a schema.custom value in the form <app-key>:<field-type> — for example com.pyxis.greenhopper.jira:gh-lexo-rank. Group by the part before the colon and you have a list of which apps own which fields.

An app used only through its own screens may touch no configuration at all.
Forge apps identify themselves by installation ID (an ARI), not by their Marketplace key, so they will not match names on your invoice.

Proves: a shortlist. Apps whose value is rendering reports or panels create no configuration at all and will look unused when they are not — we confirmed this with a real installed app. Never cancel on this signal alone.

4. Ask the vendor

Many vendors can pull usage figures for your tenant on request, because their own backend records it. It costs one email and often gives a better answer than anything you can measure yourself.

Proves: a lot — but you are trusting a party with an interest in the renewal.

5. The scream test

Unsubscribe from a suspected-unused app roughly 30 days before renewal while leaving it installed, and see whether anyone objects. Crude, and genuinely effective. Atlassian's soft delete makes it safer than it used to be.

Proves: definitively — at the cost of possibly disrupting someone.

6. Portfolio Insights

Atlassian shipped a beta for app portfolio discovery in April 2026. It helps you see what exists across your org, but at the time of writing it does not include per-app usage metrics. Worth watching; not yet an answer.

Proves: what you have, not what you use.

Which method to use when

Method	Effort	Best for
API request logs	Needs Atlassian Guard Premium or Cloud Enterprise, plus time to accumulate	Confirming an app is used
Configuration footprint	Medium manually, low automated	Producing the shortlist
Ask the vendor	One email	Apps where you already suspect the answer
Scream test	Low effort, real risk	Final confirmation before cancelling
Portfolio Insights	Low	Inventory across many sites

The practical sequence: use configuration footprint to build a shortlist, confirm with API logs or the vendor, then scream-test anything still ambiguous before the renewal date.

The obvious endpoint is closed. The information is not.

A natural question is why no Marketplace app simply lists your installed apps and checks each one. We tested this directly while building ours, and got the answer wrong the first time.

The Universal Plugin Manager endpoint (/rest/plugins/1.0/) and the Connect add-ons endpoint both return 401 Unauthorized; scope does not match to an app, under every scope and authentication combination we tried — app-level and user-level, classic scopes and granular. No published scope covers those paths. We concluded that apps simply cannot see other apps, and designed around it.

That conclusion was wrong. App identity leaks through a surface that is not an app-management API at all: /rest/api/3/users/search returns bot accounts with accountType: "app", one for each installed app. It is more complete than the plugin manager, which omits every Forge app even for an administrator's own token. Verified live: 18 app accounts, covering every third-party app on the test site.

The generalisable lesson, which cost us a day: "the obvious endpoint is closed" is not the same as "this information is unavailable". Before designing around a limitation, check the surfaces that carry the same information incidentally.

Try the configuration-footprint method now

We built a free page that does step 2 for you. Paste the output of /rest/api/3/field/search and it groups every custom field by owning app, separating Atlassian's own from third-party Marketplace apps. It runs entirely in your browser — no install, no signup, and no network calls of any kind.

Open the free checker Nothing uploaded. Works offline.