.webp)
Atlassian Cloud Release Notes Are Moving Out. Here's the Mail Worth Forwarding.
The most consequential line in the latest Atlassian Cloud release notes is not about Jira, Rovo, or automation. It is the banner at the top of the page. Atlassian is moving its cloud release notes to a new home called What's new across Atlassian, and the weekly Atlassian Cloud changes page will stop being updated after September 30, 2026.
That felt like a good reason to read the outgoing mail before it gets forwarded. I went through the September roundups, which carry forward every change still rolling out, alongside the announcements Atlassian published since mid-August. Most of it is the normal churn of a platform that ships constantly: restyled tables, new filters, a keyboard shortcut here and there. A handful of changes, though, will reach your users, your administrators, or your December invoice. Those are below, with Atlassian's release state attached, because “rolling out” and “on your site today” are not the same sentence.
The release notes themselves are changing address
According to Atlassian, What's new across Atlassian includes everything the old page carried, plus rollout statuses, search, and filtering. It lives at community.atlassian.com/release-notes. The practical impact is small and easy to miss. If a Confluence page, a weekly platform review, a browser bookmark, or a homegrown script points at the old confluence.atlassian.com/cloud/blog address, it will quietly go stale in October. Nothing breaks. You simply stop hearing about changes, which is worse.
The rollout status is the genuinely useful upgrade. The old format flagged changes as rolling out and left you to discover whether your own site had them yet, which is how “is this on our instance?” became a recurring question in every admin channel.
Automation's Usage tab now shows what December will cost
In the September 7 to 14 roundup, Atlassian redesigned the Usage tab in Automation, and it explained why in the first sentence: to help customers prepare for upcoming billing changes. The refreshed tab shows Automation usage and Rovo usage cards, plus a High usage flows table that identifies which rules contribute most to Automation steps and Rovo credits consumption. The change is rolling out.
The billing change it prepares you for was announced September 1. Per Atlassian's usage-based pricing announcement, allowance limits and billing for Rovo credits, Automation steps, and AI agent resolutions take effect on December 3, 2026. Atlassian defines Automation steps as the execution steps within an automation flow: triggers, conditions, actions, and branches. We walked through the whole model in our breakdown of Atlassian's usage-based pricing. The new Usage tab is where that model meets your actual rules.
Open the High usage flows table this week rather than in November, and expect the top of the list to surprise someone. The usual suspects are an old scheduled job nobody remembers creating, a rule that fires on every field edit, or a branch that iterates over far more work items than intended. If your automation estate grew without an owner, the automation governance habits we wrote about back in March just acquired a price tag.
Jira's configuration limits stopped being suggestions
Also in the September 7 to 14 notes: Jira now enforces limits on configuration entities, including field options, workflows, statuses, components, priorities, versions, security levels, and permission grants. When an entity reaches its maximum, Jira blocks the action and shows a message that identifies the limit, along with guidance on reducing usage. The following week, Atlassian added field options and work item security levels to the Site optimizer so admins can watch those numbers before they hit the ceiling. Both changes are rolling out.
This continues a direction Atlassian set earlier in the year, when it announced guardrails of 150 work types per work type scheme and 700 fields per field configuration. It is a reasonable direction. Sprawling configuration is a real performance problem on large sites, and every long-lived instance carries some. The operational risk is timing. Limits are rarely discovered during a quiet afternoon of cleanup. They are discovered by someone adding a version the day before a release, or a status in the middle of a process change, who then learns the fix involves a governance conversation nobody scheduled.
Run the Site optimizer now and look for anything trending toward its limit. If your instance accumulated configuration the way most do, the Jira Spaces governance model we laid out in June is a sensible place to start untangling it, and Atlassian's page on Jira data limits and guardrails has the specifics.
Company-managed boards get the modern engine
Boards in company-managed software spaces are moving to the modern board that team-managed software boards received in July. Per the September 7 to 14 release notes, a board that includes work items from only one space receives the modern board automatically, while boards that pull from multiple spaces stay on the classic experience for now. Atlassian's community post on the change describes a phased rollout that starts with Free plan customers and continues over the coming months.
The same post lists what changes. The 5,000 work item limit on boards goes away, with work items, columns, and swimlanes loading as you scroll. List view filtering comes to the board, and admin-defined quick filters remain but are renamed custom filters. Admins can save a default board configuration. There are gaps worth knowing before your teams find them: bulk selecting and transitioning cards was still in development during the early access program, and the Kanban option to create a release from the board was not supported and, in Atlassian's words, will likely be sunset.
Two practical implications follow. First, most organizations will run two board experiences side by side for a while, because multi-space and global boards stay classic. That deserves a sentence in your user communications before someone files a bug about it. Second, Kanban teams that ship releases straight from the board need a new habit before the change reaches them. For the foundation this is built on, see our read on Jira's Summer 2026 release and its rebuilt views.
Agent sessions are now visible to the whole team
Until this change, a Rovo agent session on a Jira work item was private to the person who started it. Per the September 7 to 14 release notes, anyone with access to a work item can now see all agent sessions started by their team, with teammates' sessions shown view-only. Atlassian frames this as making automated work visible and accountable, and I agree with the framing. An agent that changed a shared work item should not keep a private diary about it.
It is still a behavior change, and it deserves an announcement rather than a discovery. Anyone treating agent sessions as a personal scratchpad should know their teammates can now see them. The same week brought an Agents adoption dashboard under Reports and the option to wire the Jira Triage Agent or Jira Coding Agent into a new space at creation time for sites with Rovo enabled, both rolling out. Agents are moving from something individuals try to something teams inherit by default, which makes the permissions underneath them matter more. Our look at how Atlassian agents enforce your permissions exactly as written explains why that audit belongs first in the queue.
Smaller changes worth a sentence
- Rovo search across sites. Users with access to multiple sites in the same unit can include results from up to five connected sites in a single search (rolling out, September 7 to 14).
- Goal types in the Goals app. Organization admins can define goal types and success measures to represent frameworks such as objectives and key results, and Atlassian says Focus customers on the previous version of goal types will be migrated to the new experience automatically (September 14 to 21).
- Audit logs by unit. Organization admins can filter audit log events by unit, and unit admins can view the organization-level audit log for the units they manage (rolling out, September 14 to 21).
- A new Jira Query Language function. descendantsOfTeam returns work belonging to a team and all of its sub-teams in Jira and Jira Service Management (rolling out, September 14 to 21).
Who should care, and who can relax
Platform owners and organization admins should care about all of it. Whoever owns the Atlassian budget should care about the Usage tab, because it is the only item here with a date that turns into money. Team leads and delivery managers should care about the boards, and everyone using Rovo agents should hear about session visibility from you rather than from a colleague. A single-site organization with light automation and no agent rollout can mostly relax, apart from updating the bookmark.
The Avaratak Take
Read the last several weeks together and a pattern shows up. Atlassian keeps shipping the instrument panel a few weeks before the consequence. The Usage tab arrives ahead of the December meters. The Site optimizer learns about field options and security levels as limits on them start being enforced. Adoption dashboards and shared session views arrive as agents become a default in space creation. Even the release notes are being replaced by a format that shows rollout status. That sequencing is considerate. It only helps if someone is actually reading the gauges.
So my main recommendation is organizational rather than technical: give the release notes an owner. One person, one weekly slot, three questions for every item. Will it change what users see? Will it change what admins can do? Will it change what we pay? Anything that earns a yes gets a line in your change communication. That is roughly thirty minutes a week, and it is the difference between announcing the new board and fielding tickets about it.
The item I would act on first is the Automation Usage tab. The limits and the boards are worth preparing for. The meter is worth reading now, while the reading is still free.
If you want a second set of eyes on which of these changes lands hardest in your environment, Avaratak's senior Atlassian consultants do this kind of triage every week, and we are happy to help separate the change that matters from the change that just moved a button. Book a discovery conversation whenever it is useful.