Atlassian added usage-based billing to its paid plans, on by default

The change

On September 1, 2026, Atlassian announced usage-based pricing for its paid cloud plans and, within a day, updated three legal documents to carry it: the Atlassian Customer Agreement, the Product-Specific Terms, and a new standalone document, the Usage-Based Offering Terms. All three are marked effective October 1, 2026.

The notice Atlassian added to its legal hub states the timing in one sentence: "While the updated terms take effect on October 1, 2026, extra usage billing won't begin until December 3, 2026 at the earliest, unless you are an existing Assets or Bitbucket customer already being billed for extra usage."

Jira and Confluence sit in most software companies' stacks, so this is a billing model change that reaches a large share of the SaaS market at once.

What changed

1. A new row in the Product-Specific Terms. The table that maps each Atlassian product to its governing terms gained an entry for "Usage-Based Offerings", pointing to the new Usage-Based Offering Terms, with a footnote: "The Usage-Based Offering Terms apply in addition to any other Product-Specific Terms applicable to any Product or offering that includes the Usage-Based Offering." The document's effective date moved from November 10, 2025 to October 1, 2026.

2. A hook in the Customer Agreement. The October 1 version of the Customer Agreement adds Section 4.7: "Cloud Products may be, or include access to, Usage-Based Offerings. Atlassian provides Usage-Based Offerings under the Usage-Based Offering Terms." The definition of Scope of Use now includes "number of queries, requests or other usage-based units" as a basis for entitlements.

3. A new document with its own rules. The Usage-Based Offering Terms are where the substance lives, and they state up front: "These Terms control in the event of a conflict with the Agreement."

What the new terms say

The document defines meters, allowances, packs and extra usage. Each meter tracks consumption of a capability at the organization level, in units such as credits, objects or resolutions. Paid plans include a monthly allowance. Above that, the default is set by one sentence:

"By default, usage above Customer's Allowance and any applicable Pack is enabled ("Extra Usage"). Customer may update this default and set limits on Extra Usage at any time."

Extra usage is invoiced "in arrears at its then-current rates". Four further clauses shape the bill:

• Unused allowance expires: "Any unused portion of an Allowance or Pack expires at the end of the relevant period and does not roll over. Atlassian does not provide refunds or credits in this event."

• Consumption rates can change: "Atlassian may update the rate at which each Usage-Based Offering consumes Consumption Units."

• Automated use counts: the customer is responsible for consumption "including use due to actions of Users, Agents, and Third-Party Products and due to configurations (for instance, a scheduled automation run)."

• No returns: "Any return policy in the Agreement does not apply to Packs or Extra Usage."

The terms include a worked example: a customer with 20 Confluence users and 10 Rovo credits per user has a 200-credit monthly allowance. In a month where the team consumes 250 credits, the 50 above the allowance are extra usage, invoiced in arrears.

What the meters cover

Atlassian's usage-based pricing page lists the meters: Rovo credits for AI features, automation steps, Assets objects, Bitbucket build minutes and storage, and AI agent resolutions in Customer Service Management. The same page states that admins receive alerts at 80% and 100% of an allowance, that extra usage can be disabled or capped per meter in Atlassian Administration, and that Rovo credit pricing applies to usage from August 31, 2026. It also notes that enriched Teamwork Graph API and tool calls, the kind made by AI agents and MCP integrations, now consume Rovo credits, while embedded AI such as summaries stays free.

Why this matters

For a decade, an Atlassian bill was a seat count times a rate. From December 3 it becomes a seat count plus whatever the organization's automations, AI features and agents consumed above the allowance, at rates Atlassian can revise, with the overage switch in the on position unless an admin turns it off.

Three details deserve a close read. First, consumption is attributed to the customer even when a scheduled automation or a third-party app triggers it, so a rule written two years ago can generate a charge. Second, allowances reset monthly and do not roll over, so a quiet month does not bank capacity for a busy one. Third, the usage terms override the Customer Agreement where they conflict, and the return policy does not reach packs or extra usage. This is the same shape we described when Google Cloud added new billing triggers and when DigitalOcean made spend commitments non-cancelable: the price of a product changes through the document, not the price list.

Atlassian did give notice. The legal hub carries the announcement, the usage page carries a timeline, and the December 3 billing start leaves three months to review. The point is what that review has to cover: a new document most customers have never opened, which now controls over the agreement they signed. That is the category of change that makes tracking vendor legal documents a live control rather than an annual task.

Potential impact

Companies on paid Atlassian cloud plans may want to check whether:

• extra usage is enabled on their organization, and whether a per-meter limit or an off switch fits their budget process better than the default

• existing automation rules, integrations and AI agents draw on metered capabilities, since their consumption counts against the allowance

• the included allowance for their plan tier covers current usage, which Atlassian says has been visible in Atlassian Administration since September 1

• a negotiated agreement or order overrides the online terms, given that the usage terms control in a conflict with the Customer Agreement

Keeping that picture current across every metered vendor in a stack is the work of vendor contract monitoring, and our guide on how to monitor vendor terms of service covers a repeatable workflow for it.

How Venpo detected it

Venpo runs continuous monitoring on Atlassian's legal documents and picked up the update on September 2: the new usage-based row and effective date in the Product-Specific Terms, the effective-date change in the Customer Agreement, and the announcement and December 3 note added to the legal hub. Every quote above from those pages traces to inserted text in the redline, and every quote from the Usage-Based Offering Terms was checked against the live document. Because the substance moved into a brand-new document, Venpo added the Usage-Based Offering Terms to Atlassian's monitored set the same day, so the next edit to consumption rates or defaults will show up as a diff.

Business outcome

Teams that caught this change early were able to:

• decide on extra usage settings before December 3 instead of after the first overage invoice

• inventory automation rules and AI agents that consume metered units

• size their allowance against real usage while the meters were visible but not yet billed

• record in their vendor file that the usage terms now control over the Customer Agreement

The alternative is a line item in January that no one budgeted for, generated by a rule no one remembers writing.

Key takeaway

Atlassian moved the meter into the contract. The seat price is unchanged, the allowance is real, and the overage is on by default, invoiced in arrears, at rates the vendor can revise. The one place all of that is written down is a document that did not exist a month ago, which is why automated monitoring beats scheduled review for exactly this kind of change, the same lesson as when GitBook rewrote its AI policy into a longer, more precise document that most customers never reopened.