Atlassian

Jira’s Next Data Limits Land in Sep 2026: Here’s How to Get Ready Responsibly

Share:

Back in March 2026, Atlassian’s first wave of Jira Cloud data limits kicked in – a hard cap of 700 fields and 150 work types per space. We covered what that meant for your teams, and how Optimizer’s field-limit health check and Field Count Column could help you prepare, in our earlier post.

If you dealt with that one, brace yourself: wave two is coming in September 2026, and it’s arguably the trickier of the two.

What’s changing in September

According to Atlassian’s own documentation, starting in September 2026 the Jira Cloud family of apps will enforce a new set of limits and guardrails, including:

  • Workflows: max 150 per space

  • Workflow statuses: max 200 per workflow

  • Priorities: max 100 per space

  • Field options: max 20,000 per field

  • Components: max 10,000 per space

  • Releases: max 15,000 per space

  • Permission grants: max 50 users/space roles/groups per permission

  • Work item security levels: max 50 per space

Atlassian’s advice is consistent with wave one: audit your usage, and delete what’s no longer needed. Sensible enough, until you actually try to do it.

Why this wave is scarier than the last one

A custom field that’s not on any screen is relatively easy to reason about. A workflow status or priority is a different animal entirely.

Statuses and priorities don’t just sit quietly in a configuration screen – they’re woven into JQL filters, saved dashboards, automation rules, SLA calculations, and years of historical work items. A status that looks abandoned today might be the one thing a single team relies on every quarter, or the trigger condition buried inside an automation rule nobody’s touched since it was written. Delete it to get under Atlassian’s new cap, and you don’t find out it mattered until something breaks.

That’s the real problem admins are facing this time: it’s not that cleanup is hard to plan – it’s that “unused” is hard to prove.

The question every admin is stuck on

Atlassian’s guidance boils down to “review your usage and remove what’s stale”

Fair advice. But a smart table or a config screen only ever shows you a snapshot. The thing you actually need to know before making an irreversible call is:

“Has this been used at all over a meaningful stretch of time – or has it just been quiet this week?”

Chasing that answer manually usually means pinging every team lead who might conceivably still use a status or priority, and waiting on Slack silence to count as confirmation.

It’s slow, it’s imprecise, and “nobody replied” isn’t the same as “nobody uses it.”

Enter Monitoring

This is exactly the gap Optimizer’s new Monitoring feature closes.

Instead of a point-in-time snapshot, Monitoring tracks the live usage of specific configuration items – daily – for as long as you tell it to. Once you add an item to monitoring, Optimizer checks, once a day, whether it’s been used or modified, and builds up a dated usage record you can actually trust.

Monitoring currently supports:

  • Filters and Boards
  • Custom Fields
  • Labels
  • Work Item Link Types
  • Spaces
  • Work Types
  • Statuses
  • Resolutions
  • Priorities

Notice that last three – Statuses, Resolutions and Priorities are exactly the item types Atlassian’s September limits are asking you to trim. And Custom Fields and Work Types (wave one) are covered too, so if you’ve already been through that round, this is the natural next step.

How it works

  1. Start from the smart table you’re already using. Go to the relevant table – say, Statuses or Priorities – and select the items you’re considering removing.

  2. Add them to monitoring from the bulk actions menu. There’s a limit of 50 monitored items per configuration item type, so prioritise the ones you’re genuinely unsure about.

  3. Let it run. Optimizer scans daily and quietly builds up usage data in the background – no manual chasing required.

  4. Check the Monitoring page. You’ll see, for each item, exactly how much (or how little) it’s been used since you started watching it.

  5. Make the call with evidence, not a guess. If it’s genuinely dead, delete it straight from the Monitoring page – the deletion still goes through Optimizer’s normal review queue like any other bulk action. If it turns out to be quietly load-bearing, you’ll know before you break anything.

You can also adjust the default monitoring duration, reset the collected data if you want a clean second look, or stop monitoring an item at any point – it’s built to fit around however long your cleanup window actually needs to be.

Start now

Atlassian is asking admins to make bold, largely unalterable decisions about their Jira configuration twice this year. Monitoring doesn’t change what you have to decide – it changes what you’re deciding with. Instead of “I’m fairly confident nobody uses this,” you get a dated, factual answer: used, or not, over the exact period that matters to you.

If you’re already using Optimizer to prepare for the September limits, Monitoring is available now on v10.0.0 and above – read the full documentation here to get started.

If you’re not using Optimizer yet, this is as good a moment as any to see what it can do – try it on the Atlassian Marketplace.

Frequently asked questions

What are Atlassian's new Jira Cloud data limits in September 2026?

Starting in September 2026, Atlassian enforces new hard limits on Jira Cloud configuration, including 150 workflows per space, 200 statuses per workflow, 100 priorities per space, 20,000 field options per field, 10,000 components per space, 15,000 releases per space, 50 permission grants per permission, and 50 work item security levels per space.

How is the September 2026 update different from the March 2026 Jira data limits?

The March 2026 update capped fields (700 per space) and work types (150 per space). The September 2026 update adds a second set of limits covering workflows, workflow statuses, priorities, field options, components, releases, permission grants, and work item security levels.

How do I know if a Jira status or priority is safe to delete?

A configuration table only shows a point-in-time snapshot, not whether an item is used occasionally over weeks or months. Optimizer for Jira’s Monitoring feature tracks an item’s usage daily over a set period, giving admins a dated usage record before they decide to delete it.

What is Optimizer's Monitoring feature?

Monitoring is a feature in Optimizer for Jira that tracks the live, ongoing usage of flagged Jira configuration items – such as statuses, priorities, custom fields, and filters – so admins can confirm an item is genuinely unused before deleting it. Full details are in Optimizer’s Monitoring documentation.

Which Jira configuration items can Optimizer's Monitoring feature track?

Optimizer’s Monitoring feature currently supports Filters, Boards, Custom Fields, Labels, Work Item Link Types, Spaces, Work Types, Statuses, Resolutions, and Priorities.

Is Optimizer's Monitoring feature available now?

Yes. Monitoring has been automatically applied to all sites running Optimizer for Jira v10.0.0 or above since it shipped on 1 July 2026.

In this article:
Picture of AppFox
AppFox