A Jira Standard seat now includes 25 Rovo credits a month. A single quick Rovo chat message costs 10 of them. That is two and a half questions per user per month before the meter starts running, and on December 3, 2026, it starts running for real.
December 3 is the day Atlassian begins billing extra usage on five metered capabilities: Rovo credits, Automation steps, Assets objects, Bitbucket meters and CSM AI agent resolutions. It follows the October 13 list price increase that lifted most Jira, Confluence and Teamwork Collection plans by roughly 7 to 10%, according to Sketch Development’s breakdown of the fall changes. For a small team on monthly billing, Jira Standard went from $9.05 to $9.70 per user, per Breeze’s price comparison.
Most commentary on Atlassian usage-based pricing treats December 3 as a bill-shock event. For most organizations it won’t be. The overage rates are low and the dollar amounts in realistic scenarios are modest. The bigger risk is what admins do when they first see a usage line on a Jira invoice: switch extra usage off. That setting does more damage than the meter.
Twenty-five credits is a sample, not an allowance
Atlassian’s Rovo credits documentation sets the included pool per user per month by plan: 25 on Jira and Confluence Standard, 70 on Premium, 150 on Enterprise. Teamwork Collection and Service Collection get ten times that: 250, 700 and 1,500. A quick-answer chat message is 10 credits. A basic agent invocation is 10 credits. “Think Deeper” chat and advanced agents with model selection consume a variable amount based on reasoning steps, tools invoked and model power. Anything past the pool costs $0.01 per credit.
Run the numbers on a 200-person organization on Jira Standard. The pooled allowance is 5,000 credits, which buys 500 quick chats a month across the whole company. If 60 people become regular users at 20 quick questions a month, that is 12,000 credits and $70 of overage. Not a budget event.
The number to watch is not the quick-chat rate. It is the variable one. A team that standardizes on an advanced agent for triage or code review can consume many times the flat 10 credits per call, and that is the line that will move. The other number to notice is the tenfold gap between standalone apps and Collections. Atlassian is pricing the AI allowance to make Collections look cheap once usage grows, which means the December meter doubles as a sales argument for your next renewal. Treat it that way: model your actual credit consumption before you accept a Collection upgrade pitched on “included” AI.
Where the automation meter actually burns
Automation is the meter more likely to surprise a mature Jira shop, because the rules already exist and nobody wrote them with a per-step price in mind. Atlassian’s automation usage page defines the unit: every trigger, condition, action, branch and loop that runs counts as a step. Allowances are pooled across the organization:
| Product | Standard | Premium | Enterprise |
|---|---|---|---|
| Jira | 400 per user | 750 per user | 1,000 per user |
| Confluence | 100 per user | 250 per user | 500 per user |
| Teamwork Collection | 2,500 per user | 5,000 per user | 7,500 per user |
| Jira Service Management / Service Collection | 3,000 per user | 6,500 per user | 9,500 per user |
Extra steps cost $0.50 per 1,000. The detail that matters for cost is buried in the counting rules: a condition that evaluates to false still counts as a step. A rule that fires on every work item update, checks whether the item belongs to the right project and then does nothing still costs two steps per update.
Take a 500-user Jira Standard site with a pooled allowance of 200,000 steps. If the site logs 100,000 work item updates a month, one catch-all “on update, check condition” rule consumes the entire allowance on its own without performing a single action. Ten rules written that way burn 2 million steps, or 1.8 million over the pool, which is $900 a month. That is $1.80 per user, close to a fifth of the $9.70 small-team Standard seat price, spent on rules that mostly decide not to act.
Enterprise customers have a specific reason to look: Atlassian’s automation licensing page confirms that “Enterprise plans will no longer have unlimited automation.” Teams that grew their rule libraries on an unlimited plan have never had a reason to audit them.
The off switch is the riskier default
Extra usage is on by default. Each meter can be capped or switched off in Atlassian Administration, and the change takes effect immediately, per Atlassian’s usage-based pricing overview. The instinct of a cautious admin is to flip it off and see what happens. Here is what happens when a meter hits its allowance with extra usage disabled:
| Meter | What stops |
|---|---|
| Automation steps | New flows stop, manual runs stop, and events during the pause are not queued or replayed |
| Rovo credits | Billable AI interactions pause; free AI features continue |
| Assets objects | Object creation and updates pause |
| Bitbucket meters | Pipelines stop until the monthly reset |
| CSM AI resolutions | Requests route to human agents |
The automation row is the one to read twice. Atlassian’s automation page states that events occurring during the pause are not queued or replayed. If your service desk assigns tickets, starts SLA clocks or escalates priority one incidents through automation, a mid-month pause means those events simply didn’t happen, and nothing catches up when the allowance resets. A blocked Bitbucket pipeline means no deploys until the first of the month. A paused CSM agent moves the cost to your support headcount instead of eliminating it.
In IT operations at a large telecom, the automation that caused the worst incidents was never the rule someone had designed carefully. It was the old catch-all trigger that nobody remembered owning, firing on every ticket update. A hard stop on that pool doesn’t save money; it converts a $50 overage into an outage review.
Set the caps before December 3
Atlassian gives you about a month and the tools to do this properly.
Pull the baseline first. The Platform usage dashboard shows up to 90 days of consumption per meter and exports to CSV, as Sketch Development notes. Ninety days covers a quarter-end, which is when automation and service desk volume usually peak.
Cap, don’t switch off. Set a per-meter usage limit sized from that baseline plus headroom. A cap set at two or three times normal consumption stops a runaway rule without breaking the service desk in a normal month.
Route the alerts to someone who owns cost. Notifications fire at 80% and 100% of the allowance and of any usage limit, but only to organization and billing admins. If FinOps or IT finance isn’t in either role, the people accountable for the spend will see it on the invoice, not in the alert.
Audit the catch-all rules. Sort automation rules by execution count and look for broad triggers with filtering conditions. Moving the filter into the trigger itself costs nothing, since conditions set inside a trigger don’t add steps.
Hold off on committed packs. Atlassian lists annual committed packs as “coming soon,” with a 12-month prepaid balance that expires unused. That is the same underutilization risk as an over-bought cloud reservation, and you have no consumption history yet to size it against.
Atlassian isn’t the only vendor bolting a default-on meter to a seat this quarter. Microsoft moved its CSP default for Copilot Business usage-based billing to December 1, with a default spending limit of 4,000 Copilot Credits per user per month, the same opt-out structure we covered in the direct-channel rollout. Both fit the pattern in Zylo’s 2026 index data: portfolios stopped growing, but the bill kept climbing as seats picked up second meters. The Atlassian line is small. The habit it should start, giving every metered SaaS component an owner, a cap and an alert recipient before the first invoice, is what keeps the next one small too. If your Atlassian renewal lands in the next quarter, bring the December usage data to the negotiation rather than the seat count.