Tag Janitor

Zendesk's own Tags admin page says it in its subtitle: "See the top 100 most used tags in the last two months." Past that, it cannot tell you what is safe to delete.

Tag Janitor reads every ticket through Zendesk's incremental export, so it is capped at neither 100 tags nor 60 days.

What you get

✅ Inventory — every ticket tag: ticket count, how many closed, last used, what it is used in.

✅ Where tags are used — the reverse index: pick a trigger, automation, macro, view or SLA policy and see its tags. Not only rules: a tag no rule mentions can still be written by a ticket field option, or pushed on by an organization. A rules-only view calls that tag safe to delete; deleting it silently breaks the field. Five Zendesk-native drop-downs were writing zd_* tags on our own account, so check your Ticket fields first.

✅ Possible duplicates — clusters of typo, case and separator variants.

✅ Bulk rename, merge and delete — behind a dialog that states what will change first.

The limits, before you buy

Closed tickets depend on a setting, and it did not work here even with the setting on. Zendesk refuses tag edits on closed tickets quietly: PUT /tickets/update_many returns 200 and a completed job while each per-ticket result reads "success": false. Its Modify closed ticket setting (Admin Center > Objects and rules > Tickets > Settings) is documented to lift that for admins; we turned it on on our own trial and the edits were still rejected. So Tag Janitor promises only this: it reads the setting, says before you click how many tickets in scope are closed, attempts them anyway, and reports per ticket what Zendesk accepted.

User-tag counts are lazy, checked one tag at a time. If a check fails the app prints "could not be checked — treat as unknown, not zero". It never prints a 0 it did not measure.

This is an admin tool. Zendesk allows the incremental ticket export to admins only, so an agent account cannot scan; restrict the app to administrators at install.

The table shows the first 400 tags; narrow the search to see the rest.

The first scan reads every ticket once. It pages GET /api/v2/incremental/tickets/cursor.json at 1,000 a request, and Zendesk caps that endpoint at 10 a minute (30 with High Volume) — a ceiling near 10,000 tickets a minute. The only scan we have measured is our own trial: 314 tickets, 2,967 tags, one request, 697 ms. Not a large account. Results cache in your browser.

Data. No backend, no account, no signup: static HTML and JavaScript inside the Zendesk App Framework, every call through client.request, so it never handles your credentials. It reads tickets, users, organizations, business rules and ticket fields to build the two indexes, writes only what you confirm, and sends no helpdesk data anywhere.

About. Productivity Boost is a one-person software studio in Passau, Germany. Support by email, in English or German.