It’s Everyone’s Favorite Season Again: Everything Atlassian Just Put on a Meter

Atlassian raises prices. This is not a controversial statement, and in spite of what Atlassian Lawyers might tell TJL, it’s not a hard thing to predict. It is also not a complaint, just arithmetic. On October 15, 2025, list prices went up 5% on Standard, 7.5% on Premium, somewhere between 7.5% and 10% on Enterprise depending on user count, and a flat 10% on Bitbucket Standard and Premium. The year before that, prices went up. The year before that, prices went up. Anyone who has renewed an Atlassian cloud subscription in the last five years has a spreadsheet with a line in it that only goes one direction.

So most of the usage-based pricing announcement should not surprise anyone. If you look at the wider AI ecosystem, a meter has been coming since the day Atlassian started shipping AI features. I mean, their suppliers have to get paid too. I expected that one, and have been saying as much for months. I would have been more surprised if it didn’t happen.

I’ve also said Atlassian has a pattern. They’ll announce some flashy and large number at a Team keynote, and by the time we are filing in for the next year’s Team Keynote, we are looking at some sort of limit on that feature. They did this with Automation, where they announced at Team ’24 they had 1 billion activations per month for Automation, and a couple of Teams later we are talking about per-step metering. And I’ve been saying it since they dropped the 150 billion objects statement in the Keynote at Team ’26 – that is an impressive number, and per Atlassian habits, it will come with an equally impressive limit or cost by next year.

What I did not expect was for them to further ratchet down on automations as they did.

So, here is the tl;dr (Though, as we all know, the devils are in the details, so you should read it all). Effective December 3, 2026, Jira automation stops being counted in successful rule runs and starts being counted per execution step. What counts as a step? All triggers, conditions, actions, branches, and loops each count as one. If a step is repeated using a loop, each execution of those steps counts – which is to say long loops are going to hurt. Enterprise, which has had unlimited automation runs up to now, lands at 1,000 steps per user per month. There is no longer a tier you can buy your way onto to make this stop mattering.

That is a price increase. It is a price increase whether or not the list price on your renewal quote moves, and calling it a pricing model describes the mechanism without answering the question. Usage-based pricing does give you controls a flat increase never would, and I will spend part of this post saying where it is better than what it replaces. But a rose by any other name still has thorns.

And this particular rose has more than one thorn. Automation is one meter out of three landing that day, the rules for what happens when you run out of any limit are also changing underneath all of them, as is the licensing strategy behind the whole thing that has been sitting in plain sight since Team ’26. Automation is where you’re likely to see it first – especially if you’re used to not having to worry about it – but it is one piece of a much larger change.

So let’s dig in, see what was actually announced today, see where the hidden traps are, and what you should be doing before December 3rd to make sure you don’t have a surprise come January.

---

What Actually Changed

Atlassian’s blog frames three meters we need to track now.

• Rovo credits cover deep AI interactions: Rovo Chat, MCP usage, Confluence AI Slides, the Jira coding agent, and Teamwork Graph queries. Inline summaries, rewrites, and Rovo Search stay free. Those happen to be the features most users touch most often, so the carve-out is a real one.
• Automation steps are execution steps within an automation flow. The announcement lists “triggers, conditions, actions, branches.” The usage documentation adds a fifth: loops. Hold onto that, because it is the whole story of this post.
• AI agent resolutions are outcome-based. You are billed when an agent autonomously completes a request without escalating to a human.

Alongside the meters, Bitbucket allowances move to organization-level pooling and Assets is expanding to more customers. Both of those are objective wins and considering I’m about to tell the majority of this post how this is terrible, I should at least call the wins what they are. Atlassian has at least earned the courtesy of an accurate ledger.

Big “A” also brought its own numbers: agents grounded in Teamwork Graph context deliver 44% better answer quality on 48% fewer tokens. Treat a vendor-funded benchmark as directional rather than projectable and there is still a real claim inside it, which is that grounding an agent in your own data makes it cheaper to run. Under a credit meter, that stops being an engineering nicety and becomes a budget input.

---

The Automation Meter Changes the Unit of Measure

Here is what surprised me, and I think will also get most Admins. Atlassian is changing what is counted rather than how much each unit costs. I share public information, but as a partner (and also a customer and journalist, kinda), I do have some access to privileged info. As such, I usually make a practice that I don’t review any partner information unless it’s been specifically shared with me as “The Jira Guy” with a defined embargo date. That is to say I’ve been hearing rumors for a few weeks, but I specifically didn’t look at this until right before you guys knew about it yesterday.

Two effects of that. First, when the Atlassian Lawyers (our favorite villains) say I leaked something, I can objectively say it was a prediction, because I objectively didn’t know. Second, and most important – yes, I did write this within the past day.

So I found out yesterday that Automations were changing as a part of this information, so I’m figuring this out with everyone else. But here is what I figure.

Automation in Jira Cloud has been counted in successful rule runs since November 1, 2023. That model was mostly generous: limits moved to per-product rather than one shared pool, only successful runs counted, and log actions, variable creation, and refetches stopped consuming allowance. Under it, one rule execution that performs at least one action is one unit, no matter how many actions it performs. A rule that transitions a work item is one run. A rule that branches across forty linked work items, evaluates a condition on each, edits a field on each, and posts a comment on each is also one run. With me so far?

Under what was announced yesterday, that second rule will roughly cost a hundred and twenty two units: one trigger, one branch, and three components on each of forty items. That is my arithmetic against Atlassian’s published definition rather than a number Atlassian has quoted, and your real count will move with the shape of your data. The direction is not in doubt.

So given that, how many steps can you run in total over a month?

Product	Free	Standard	Premium	Enterprise
Jira	150	400	750	1,000
Confluence	50	100	250	500
Jira Service Management	1,250	3,000	6,500	9,500
Teamwork Collection	200	2,500	5,000	7,500
Jira Product Discovery	100	300	500	750

Put the worked example against the Jira column and one execution of one rule costs about an eighth of one Enterprise user’s monthly allowance. Run it daily and it is roughly three and a half users’ worth, for a single rule nobody has likely looked at since they wrote it.

But given that, I do want to draw your attention to two details.

First, steps are pooled across your Atlassian apps, at the organization level. Your total usage is the sum of every automation step across every product. The per-product accounting that has been in place since 2023 goes away, which means your Jira automation and your JSM automation are now drawing on the same number.

Second, failed and empty executions consume allowance. The charged statuses are SUCCESS, NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED, and NO_MATCH. Today, a scheduled rule that fires and matches nothing is free, because only successful runs count. In December it spends its trigger and its condition every time it looks. A rule scheduled every fifteen minutes that usually finds nothing runs about 2,880 times a month and costs something on the order of 5,700 steps to achieve nothing of value.

That last one is the change I would put in front of your team first, because it inverts an assumption everybody has been operating on. The current model charges you for work performed. The new one also charges you for work attempted.

One honest caveat on all of this. Because the allowance is pooled and granted per user, a large organization with modest automation will now have enormous headroom, and none of these numbers will register. The exposure concentrates in the shops with heavy automation relative to headcount, which in my experience is exactly the shape of a good platform team: fifty people who automated everything rather than five hundred who automated nothing. The instances that did the work best are the ones that will feel this first.

---

The Hard Stop Becomes a Bill

There is a second change underneath the counting change, and it is one I am in two minds about.

Today, when you hit your automation limit, rules for that product stop until the calendar month resets. That is a hard wall. You get an email, your automation dies, and someone (who, let’s face it, is going to be the Atlassian Admin) now has to go through and fix everything that didn’t get done for the SLA rules that stopped firing on the fourteenth.

In December, paid plans get an overage instead. And to be clear here, I do think this is the right direction. I’m not writing this section to call Atlassian out – I’ve asked for this setup more than one time. Extra usage is enabled by default, metered features keep running without interruption, and the charge lands on your next invoice at the end of the billing period. Which is how a December change becomes a January problem.

I want to give Atlassian credit here, because this is the better failure mode for most people most of the time. Critical automation that silently stops mid-month is worse than a line on an invoice. If your change management, your incident routing, or your access provisioning runs through automation rules, having them keep working while finance sorts out a charge is the right default. Anybody who has cleaned up after a mid-month automation outage knows the wall was never a feature.

And to be clear – if you disagree, the old wall is not gone, it’s just a setting now. Admins can disable extra usage, and if you do, your billable interactions stop until usage resets on the first of the following month. Better still, there is a third option that did not exist before: leave extra usage on and set a monthly spending limit. Not zero, not unbounded, but a number you chose. For anyone who has had to explain an automation outage to a service owner and a surprise invoice to a finance partner in the same quarter, that is the option you actually wanted.

I think this is exactly as this should be set up. Flexible enough you can control it to best suit your organization’s needs. I spend enough time complaining about assumptions Atlassian makes that should be settings, it’s nice to see them actually get it right.

One caveat I could not resolve, though: the extra usage toggle and the spending limit are documented for Rovo credits. Whether the same controls cover automation steps is an assumption for me, but it’s not stated anywhere I could find, and if you run heavy automation that is the first question I would put to your account team. Either way the action is the same. Go into Atlassian Administration and decide deliberately what you want to happen on the day you run out, because right now that decision has been made for you, and it was made in the direction of the invoice.

---

The Traps Are in the Rules You Were Right to Build

trap (noun) – something by which one is caught or stopped unawares – Merriam-Webster Dictionary

So, let’s assume this new pricing model for Automation has traps. What do they look like? Well, for this they aren’t so much hidden, more they are counterintuitive – which might actually be worse. You may believe you are doing this by the best practice and fall into one before you realize it.

One easy one I’ve set up and would totally fall into now is anything using a create work-item trigger to set a field. That is – on its own – two executions for every work item created in your project or instance. Now think about how many work items you create per day, especially if it’s a global rule. Best case scenario here is you build some condition into the trigger. That stops additional steps and therefore usage, but it doesn’t go to zero. You are still charged for that initial trigger, even though it didn’t succeed.

Another expensive rule to consider is when branching is involved. For example, branch over the children and roll up a status. Query a lookup table to decide which team to route to. Walk a set of linked work items and reconcile them. Run a scheduled JQL sweep every morning and act on whatever it returns. Those are the rules that replaced a human doing something tedious forty times a week, and they are exactly the rules whose step count scales with your data rather than your configuration.

That last category is the one I would look at first. A scheduled rule with a JQL trigger costs you in proportion to how many work items match, and that number grows without anyone deciding it should. A sweep written two years ago against a project with 300 open items is doing something very different today against a project with 4,000, and nothing in the rule changed. Nobody edited it. It got more expensive because the backlog got bigger, and no amount of rule hygiene flattens that curve on its own.

Then there is the crossover case. Atlassian shipped a “Use Rovo” action inside Automation, so a single rule can now consume automation steps and Rovo credits in the same execution. Nothing I have found says how the two meters interact at that boundary. If you are building agentic automation, and Atlassian is very clearly encouraging you to, you are building on two meters at once.

None of this is a reason to write worse automation. It is a reason to know which of your rules are the expensive ones before somebody in finance asks you.

---

The Risk Atlassian Is Running

I want to be careful here, because many others have said “This is going to end in a mass-migration away from Atlassian,” and if the Server and DC migrations haven’t scared people away en masse, I doubt this will be the straw that breaks the camel’s back. As I opened with, we, as Atlassian Admins, are no stranger to yet another price increase.

And there is also the fact I make my living in the Atlassian system, just like the majority of you. I have every reason to root for them as my team.

But I’d be neglectful if I didn’t share my thoughts on this. And the Enterprise change is a different kind of move from the rest of it, and I think it is worth naming what it puts on the table. Unlimited automation runs were not a line item on an Enterprise quote. They were a reason to choose Enterprise. It was among the top selling points. Removing an unlimited tier changes what a customer is buying, and it does that for the segment with the most complex platforms, the most internal tooling built on top of Atlassian, and the most bargaining power in a renewal conversation.

Those customers have a spreadsheet too. When the automation they built to replace headcount starts carrying a per-step cost, the build-versus-leave conversation stops being theoretical, and a platform team that spent three years proving it can automate anything knows how to evaluate alternatives. I am not predicting an exodus. I am saying Atlassian has handed a specific and capable group a concrete reason to open the question, and that is not the group you want opening it.

As I said, I would rather be wrong about this, and for most I still don’t think this is enough to push them away. But the counterargument is real: metering is how every platform vendor has moved, the controls beat a blunt list-price hike, and most organizations will land inside their allowance and never think about it again. I’m convinced someone is going to start at least asking the question.

And the thing that might have taken the edge off this has not arrived. Flex, the fixed wallet Atlassian announced at Team ’26, still has no ship date, no named customers, and a contact form for a front door. I’ve talked with customers who are on an Enterprise license and it has not materialized for them. The meters have a deadline. The wallet does not.

---

The Escape Hatch Is Not Leaving Atlassian

Before anybody migrates off the platform, most shops will do something far cheaper. They will move the work out of Automation and into an app.

JSU, JMWE, Power Scripts, ScriptRunner (among many others). Those execute in their own runtime, fired by workflow transitions and Jira events rather than by Automation rules, so they never touch the step meter. In a few cases they do things Automation cannot do natively, and most admins who have been in this ecosystem more than a couple of years already know at least one of them well enough to be dangerous.

I do not want to sell that as a free lunch. Anyone who has ever priced out a marketplace app knows it is not. You are trading a metered spend for app licensing that scales with your user tier, for scripting complexity that a smaller group of people can maintain, and for the hours it takes to rebuild rules that already work. You are chasing complexity and time in exchange for money. Your currency mix may vary, and for plenty of shops the overage will come in cheaper than the app plus the labor. Especially if they already had the apps in question.

It is also worth asking how long “off the meter” lasts. Forge usage already shows up as a line item inside Flex, which tells you Atlassian is thinking about app compute in the same units. Apply the pattern from the top of this post and draw your own conclusion.

The strategic point stands either way. Migration is rarely the first response to a new meter. Routing around it is, and Atlassian has just handed a lot of very capable admins a reason to move work off the automation engine it spent years getting them to adopt.

---

Rovo Credits Are the Meter Everyone Saw Coming

Which brings us to the meter I have been expecting for months, and the one that is easiest to plan around. Legibility counts for a lot when you are trying to forecast a bill, and this is the legible one.

Paid Jira and Confluence subscriptions carry a monthly per-user credit allowance of 25 on Standard, 70 on Premium, and 150 on Enterprise. Service Collection and Teamwork Collection run ten times those figures, at 250, 700, and 1,500. Credits pool at the organization level, reset monthly, and do not roll over. Basic AI features cost 10 credits per billable event, premium features vary with compute, and Deep Research runs 100. Ten credits per agent request against a 70-credit Premium allowance means seven agent requests per user per month before you are into the pool, and because the pool is organizational, the handful of people who live in Rovo all day are subsidized by everyone who does not. I like that design. It matches how adoption works.

The overage price is published, which is more than the automation meter can say. Rovo credits bill at $0.01 each past your allowance, $10 per thousand, and extra usage is enabled by default, so the overage is opt-out. You get notifications at 80% and 100%. Go find that switch and decide whether you want it on, because right now somebody decided for you.

To be clear – if people started using Rovo the same way I’ve seen many of you use Claude or ChatGPT, I do not think this is sustainable for organizations. If you are on Premium, and limit yourself to one agent request per day, you still run out of your share of the pool in a week. This is where the organization pool is currently carrying many of us, subsidizing those who are using Rovo with those who aren’t. If the calculus starts changing so more people are using it than are not, that model starts to look very tight indeed.

The credits have been counting all along. What arrives in December is the invoice behind them when they run out.

---

AI Agent Resolutions Are the One with a Public Price

So, we’ve talked about Automations, and Rovo – but because this can impact how companies work with their customers, this might be the most serious of the three meters.

And to be clear, Premium and Enterprise plans already include 1,000 assisted conversations per month, or 12,000 per year, for the virtual service agent. Past that, assisted conversations start at $0.30 each with volume discounts. Rovo Customer Service is included across Standard, Premium, and Enterprise at $1 per resolution.

Outcome-based pricing is honest in a way seat-based pricing is not. You pay when the thing actually works for you. If the agent deflects a password reset that would have cost a service desk agent eight minutes, a dollar is a good trade and I think most people would agree.

The place to concentrate is the definition. “Resolution” is doing enormous work in that sentence, and deflection metrics have a long history of being soft. A conversation that ends because the agent answered is a resolution. A conversation that ends because the requester gave up and walked to somebody’s desk looks identical in the data. If you are running JSM at any volume, pin down before December what Atlassian counts as a resolution, and what happens to a request that gets escalated after the agent has already engaged. The price is the easy half.

---

What I Would Do Between Now and December

Ninety days is enough time to know your own numbers, and knowing them is most of the work.

Start with the Platform usage dashboard in Atlassian Administration. It surfaces Rovo credits, indexed objects, Rovo Dev credits, and Bitbucket build minutes and large-file storage, and it requires an org admin on centralized or original user management, worth checking before you plan a meeting around it. While you are in there, find the extra usage setting and decide whether you want it on, because it is on by default. On Rovo Dev Standard there is a further auto-enabled allowance of 2,000 credits per user per month that you can turn off or change. Those settings are the difference between a controlled spend and a surprise, and most admins I talk to do not know they are there.

Then go to your automation rules and sort by last modified, oldest first. Take the five at the top and answer three questions about each one: does it branch or loop, does it run on a schedule against a JQL query, and did anyone ask for it in the last year. A rule that loops over a growing result set and that nobody has touched since 2023 is the specific shape of the problem. You need twenty minutes and the audit log.

Then do a second pass looking only for rules that fire often and match rarely. Under the old model those were free. They are not free in December, and they are the least likely thing on your instance to be documented, because nobody writes a runbook for a rule that usually does nothing.

To be clear, my team is going to be doing a full audit of all automations, but these two are a good starting point.

Add up your allowance while you are at it. Steps are pooled organization-wide now rather than per product, so the number that matters is total seats times your per-plan allowance, measured against every rule across Jira, JSM, Confluence, and JPD together. If you have been treating your service desk automation as a separate budget from your “Just Jira” automation, that distinction is gone.

Last, if you have Rovo actions inside automation rules, list them. That list is your exposure at the boundary between two meters, and it is the question I would take to your Atlassian contact before December rather than after. While you have them on the phone, ask what a step costs past the allowance. Atlassian has published the allowances and the counting rules but not the overage price, and that is the one number still missing.

---

The Version You Can Forward to Your Boss

Most of you are going to have to explain this to somebody who does not care what a branch is. Here is the compressed version, with the parts that are documented separated from the parts that are not.

What changes. On December 3, 2026, three things start billing that did not bill before: Rovo credits, automation steps, and AI agent resolutions. Automation moves from counting successful rule runs to counting execution steps.

What counts as a step. Triggers, conditions, actions, branches, and loops. Each component that runs counts once, and a step inside a loop counts on every iteration. Charged execution statuses are SUCCESS, NO_ACTIONS_PERFORMED, SOME_ERRORS, ABORTED, and NO_MATCH, so a rule that runs and finds nothing still spends allowance.

Automation step allowances, per user per month, Free per subscription, pooled organization-wide across products:

Product	Free	Standard	Premium	Enterprise
Jira	150	400	750	1,000
Confluence	50	100	250	500
Jira Service Management	1,250	3,000	6,500	9,500
Teamwork Collection	200	2,500	5,000	7,500
Jira Product Discovery	100	300	500	750

Rovo credit allowances, per user per month: 25 Standard, 70 Premium, 150 Enterprise on Jira and Confluence; ten times those figures on Service Collection and Teamwork Collection. Overage is $0.01 per credit. Extra usage is on by default.

What happens when you exceed it. Paid plans bill an overage on the next invoice rather than stopping. Free plans stop. Your automation will not go down, and that is the good news and the bad news in the same sentence.

What is not published, and what I would put in writing to your Atlassian contact rather than waiting for:

• The per-step overage price. Allowances and counting rules are published. The price past the allowance is not, and “usage packs” is referenced without figures. You cannot forecast a budget without this number, and that is a reasonable thing to say to an account team in September rather than December.
• How a rule using the “Use Rovo” action bills across both meters in a single execution.
• How this applies to an existing agreement. If you are mid-term on an annual or multi-year contract, ask specifically whether usage billing begins December 3 regardless of your term, or at your next renewal. Atlassian’s own materials say timing may vary by capability and billing cycle, which is not the same as a clear answer. Get yours in writing, because the answer determines whether this is a this-quarter problem or a next-year problem, and those are two very different conversations with a CFO.

The one-line version. Automation is being metered per step for the first time, the tier that had unlimited automation no longer does, and rules that run often or loop over large result sets are the ones that will show up on the bill.

---

Wrapping Up

Atlassian will tell you December 3 is not a price increase, and on the narrow question of list price they aren’t wrong. They are also metering something that used to be unlimited, for the customers who use it most, and counting it in a unit that charges for attempts rather than results. As they say, multiple things can be true at once, and only one of them shows up on a renewal quote.

The credits meter is legible and priced at a penny. The resolutions meter is honest and priced at a dollar. The automation meter has published allowances, a published counting rule, no published overage price, and it re-prices your best rules hardest, because a step meter charges by how much work a rule does and the good rules are the ones that do the most.

Which brings me back to the pattern I opened with. Atlassian celebrated one billion Automation activations a month from the keynote stage at Team ’24. December 3 is the other half of that sentence, arriving right on the usual schedule. They told us about 150 billion objects in the Teamwork Graph at Team ’26, and I said then that a number that big shows up with a meter attached eventually. I would not want to be the one betting against it this time either.

Go open your automation rules right now, sort by last modified with the oldest first, and look at the top five. Find the ones that loop. Find the ones running scheduled JQL against a result set that has been growing since you wrote them. Then find the ones that fire constantly and match nothing. That is a twenty-minute job and it tells you more about your December exposure than any pricing page will.

I suspect the answer varies enormously between instances and I would like to know the shape of it. If you run that check and find a rule doing far more work than you remembered asking it to do, I would like to hear about it.

Until then, this is Rodney, asking: have you updated your Jira issues work items today?

---

Enjoyed this one? These posts are free and always will be — but if this saved you a headache or taught you something worth keeping, you can drop a tip in the Ko-fi jar. No paywall, no subscription, no catch. Just a thanks if the writing earned it.

→ Support The Jira Guy on Ko-fi