How many Jira administrators do you need? What admins report and what we see

"How many JIRA administrators should you have?" was asked on the Atlassian Community in May 2015, and it has 3,378 views. The same question came back in 2018, 2021 and 2022 under slightly different titles, and the four threads together have about 21,400 views. The threads keep coming back, and none of them ends with a number you could put in a budget.

Our answer: a company of 50 to 2,000 Jira users needs two people who can do Jira admin, and at least one of them needs real, protected time for it. Past that, the headcount follows how much changes each week. New starters, access requests, new projects, schemes and apps drive it far more than the user count does. Most of the admins on those threads gave the same range for seven years: a core of 2 to 5, and under 10 even on a 5,000-user or a 30,000-user site. One was the sole admin for nearly 3,000 users, and another site had over a hundred.

We work admin queues on several of our clients' Atlassian sites, and on two mid-size ones about one person in every 30 to 50 Jira users holds an admin role. Nobody needs a dozen admins on a site that size.

We also sorted our own tickets to see what the work is made of, because the job itself changed this year. Near the end there's a sizing table, when I'd hire versus buy partner time, and what I'd do this week.

Five findings from the threads and our desks

1. The Community answer hasn't moved since 2015. Two at minimum for holidays and sickness, ideally three or four, and Atlassian's own advice is to have more than one organization admin in case an account is lost.
2. Sites hand out admin far beyond what they need. One admin-role holder per 30 to 50 Jira users on two mid-size sites we work on, and on one Data Center estate a single group carried dozens of admin members.
3. Roughly half the tickets look like seats and access. That's from 227 tickets on four sites, sorted by keyword, so it's a hint. Configuration is about a quarter.
4. The cloud split the admin into several roles. A Jira admin can't manage users. An org admin isn't a Jira admin by default. Billing is its own role, and Atlassian's billing page says an org or site admin can't reach the billing accounts page without billing admin rights.
5. 2026 added duties nobody had in their job description. Usage meters from 3 December, Rovo agent governance, the Connect end of support on 31 January 2027 and the move to field schemes.

How many Jira administrators per user: what admins reported, and what we count

I'll start with what other admins reported, because it's the biggest sample anyone has. Each row is a reply on one of the four Community threads, read on 3 November 2026.

A 2015 reply put it well: "the instinct to increase admins as the numbers of users goes up, that's not really a useful idea." A 30,000-user site ran on 5 admins plus 3 part-timers. They batched changes to twice a week.

Now ours. We counted the people holding an admin role on three sites we work, from the group memberships our desks recorded. We don't name the sites and we round everything.

On the mid-size sites that ratio means a dozen or more admins. On one of those sites, most of the people holding the role don't do admin work. My guess is the role gets handed out for a project and never taken back, but we haven't counted why. One answer on the 2021 thread described the same thing: "at one point, I found over 60 people had admin in one of the Jira systems." On a Data Center estate we measured in September, a single space group alone carried dozens of admin members.

So if you're asking how many you need: count the people who do the work, and plan for two of them. Then count who holds the role, and you'll probably want to take some away.

What does a Jira administrator do in the cloud now?

If you're writing a job description for Jira Cloud in late 2026, I'd put these seven duties in it. The list is longer than the one from five years ago, and some of it doesn't sit with the "Jira admin" at all.

1. Grant and remove access. Who gets a seat, who gets which app, which group gets into which project (Atlassian now calls projects "spaces" in Jira). In cloud this usually needs an organization admin or user access admin, because Atlassian's own page says someone with the Administer Jira permission can't "manage existing users or add new ones".
2. Configure Jira. Work types (the new name for issue types), workflows, screens, fields, permission schemes, notification schemes. This is the Jira admin's core.
3. Move to field schemes. Atlassian announced general availability of field schemes on 10 June 2026 and is retiring field configurations and field configuration schemes, rolling out progressively. If your site still shows the old screens, you haven't been switched yet.
4. Own the usage meters. From 3 December 2026 most usage meters bill extra usage, and it's on by default. Atlassian notifies org and billing admins at 80% and 100%. We wrote up what a 50, 200 and 500 seat budget looks like and how to set or turn off the extra usage limit.
5. Govern Rovo agents. Rovo Studio "is open by default to everyone in your organization", and a new agent "becomes available for everyone to see and use by default", per Atlassian's agent governance page. Somebody has to decide whether that stays.
6. Vet apps. Approve Marketplace apps, and before 31 January 2027 find the Connect apps on the site. Atlassian's developer blog says Connect end of support was extended to that date, while two of its 2025 posts still say "late 2026" and "Q4 CY2026".
7. Keep the audit trail. Without Atlassian Guard or an Enterprise plan, Atlassian says organization-level logs "will not store or display any events". With Guard Standard or Premium they're kept for up to a year. Guard costs $4.35 per user a month on Standard and $8.55 on Premium, billed monthly.

And then there are the questions. Why can't I see this project, why did this field disappear, why did I get this email? None of that is in a job description, and it all goes into the same queue.

The role split surprises people. Atlassian's admin roles page lists six admin roles, from organization admin down to billing admin, and says "for the Jira family, only an organization admin can make another user an app admin". Its global permissions page adds that an organization or site admin who wants to change a workflow has to "add yourself to the jira-administrators group" first. On our test site, Administer Jira is held by two groups.

Where Jira admin time actually goes

We took 227 tickets our desks worked on four Atlassian sites between July and November 2026 and sorted each one by the words in its own text. 198 had enough text to sort.

Please read this table as a hint. It's a keyword sort, and when we spot-checked 12 tickets at random only about 5 were clearly in the right row. One site supplied well over half of the tickets, so its mix pulls the total. A hand-labelled sample would fix it. We haven't done that yet.

If the order holds on your site too, it changes the hiring question, because seat and access tickets are the most repetitive part of the queue. On one site we work on, automating seat reclaim turned most of the "I can't get in" tickets into a self-service click. The same desk taught us to ask one question before touching an access ticket: is the fix in Atlassian or in your identity provider? A group synced from your directory can't be fixed in Atlassian, so that ticket belongs to whoever runs the directory.

If seats are your biggest line, start with inactive users. We wrote how to remove inactive users in Jira Cloud with an agent.

Team size to support Jira by users, projects, apps and JSM agents

The four Jira sites we have seat counts for run from roughly 100 to 1,700 Jira users, three of them with 80 to 200 JSM agents. Across five cloud sites, projects run from about 30 to a few hundred. Count Jira users here, not employees. For a sense of what "big" means, Atlassian's 2018 infographic on its largest Jira customers gave averages of about 1,200 projects, almost 900 custom fields, about 400 workflows and 23 apps.

This table is our judgement, built from the Community ranges and what we see on those sites. We can't give you hours per row, because our ledgers count tickets and not time, and I'd rather leave the hours out than guess them.

What moves you down a row is standardisation: shared schemes instead of one per project, a request form for access, automated seat clean-up. What moves you up is the opposite, plus JSM, because every new service space brings its own queues and SLAs, and new request types usually mean editing them. The user count shows up mostly through access tickets, and those are the easiest to automate.

Is a part-time Jira administrator enough?

Often it is, if the part-time person is named and has fixed hours for it. "3 is a minimum but they can easily be part time" was one of the 2018 answers, and the 30,000-user site ran 3 part-timers next to 5 admins. A 2022 reply said adding users to groups and projects went to general IT support, which is a sensible split.

Part-time goes wrong when it means "whoever has time". A 2021 thread on whether cloud Jira admin is a full-time role put it this way: "A lot of places throw it onto a Dev Ops person until it becomes an inevitable mess." Part-time works when it's a named person with hours in the week for it, the same backup every time, and a rule that nobody else changes schemes.

The new meters are the other reason to name someone. Our own test org was already at 4,650 of 3,990 Rovo credits on 3 November. Billing starts on 3 December. With extra usage on by default, nobody gets stopped at 100%. The org just pays for the overage. A part-time admin who checks the Meters page once a week would have seen our 117% a month early.

Jira admin vs consultant: hire or buy partner time

I'd probably hire an admin rather than a consultant when the steady queue (seats, access, small configuration changes) fills more than about half of someone's week, because that work needs someone who knows your teams and is there every day. I'd buy partner time for the work that comes in bursts and needs depth: a migration, a site merge, a scheme clean-up, moving to field schemes, auditing Connect apps before 31 January, or setting up meter limits and Rovo agent rules before 3 December. Paying a full-time salary for work that happens twice a year rarely makes sense, and a partner who has done the same clean-up on other sites will usually do it faster.

The mix I'd recommend for sites of 300 to 2,000 users is one or two in-house admins for the daily queue, plus a partner on call for projects and as the backup. You get the "minimum of 2" without paying for two full-time people. We sell this kind of partner time, so take that recommendation knowing where it comes from.

What I'd do this week

Start by counting. Open the Users page in Atlassian Administration, filter by each admin role, and check who holds Administer Jira. Then write down who actually did admin work last month. You'll probably find a long list and a short one. Take the rights away from everyone on the long list who isn't on the short one, but keep at least two organization admins, as Atlassian recommends.

Then give the meters an owner. Pick one person. They get the billing admin role and the Meters page, and you decide the extra usage limit before 3 December. Decide who may create Rovo agents while you're in there. Unless someone has changed it, it's everyone.

Then the apps. Before 31 January 2027, pull your list of Connect apps and ask each vendor about Forge. And when you have an hour, sort a month of your own tickets into seats and access versus everything else. If most of it is seats and access, automate that before you hire. If most of it is configuration, that's the work a hire is for.

If you run Jira at a company of this size, how many people do the admin work, and how many hold the rights? I'd love to compare notes, so feel free to reply on LinkedIn or email me at gabriela@leanzero.net.