Three weeks ago I put the old weekly "Atlassian Cloud changes" page next to its replacement (the side-by-side). @Mia Tamm _Simpleasyty_ made the point in the comments that the new stream is better data and a worse routine: the weekly page was somebody else's filter, and from tomorrow the filter is yours. This is the one I use.
What you are filtering now
The new home is What's new across Atlassian. Every entry has six columns: App, the note, Status (Rolling Out or Coming Soon), Change type, Impact (Low, Medium or High, still in beta), and Rollout schedule. Atlassian's own filter is Impact, and it is worth using, but Impact is their estimate of how much attention a change needs across every customer. It cannot know that your site runs on a gadget an app vendor has not migrated, or that your portal customers are all on Outlook desktop. So Impact is where you start, not where you decide.
The three questions, one per entry
For each entry with Status Rolling Out, or Coming Soon with a month attached, ask:
- Does it change what my users see? A moved button, a renamed thing, a new default. If yes, it goes in the user note, the one-paragraph message you send before the first ticket arrives.
- Does it change what my admins configure? A setting that moves, a default that flips, a permission that now exists. If yes, it goes on the change calendar with the rollout month, and someone owns checking the site the week it lands.
- Does it change what my apps depend on? A deprecated module, a changed API, an export that behaves differently. If yes, it goes to the app owners, with the vendor's name attached, because they are the ones who have to answer it.
Most entries are no to all three and take five seconds. An entry that is yes to two is the one that becomes a Monday-morning incident if nobody read it. Last week's examples on my own list: the classic dashboards replacement (yes to all three), the Confluence REST change that will require approved drafts in spaces with publishing approval (yes to admins and apps), the new Rovo MCP control inside data security policies (yes to admins, and to nobody else until you turn it on).
The fifteen minutes
Monday, before anything else. Open the table, filter to Rolling Out, sort by App, and walk the entries added since last Monday (the table has no "new since" view yet, so keep last week's count in your notes). Ask the three questions. Write the three outputs into three places: the user note draft, the change calendar page, the app-owner message. Then filter to Coming Soon with a schedule and add anything with a month to the calendar without doing more than that. That is the whole routine. It is longer than reading a digest and it is the only version where the decision about your site is made by someone who knows your site.
Three things the new table does not do for you
- It does not tell you which entries are new since your last visit. Keep the count.
- It does not know your apps. The developer changelog is where module deprecations appear first, usually weeks before the customer-facing note; skim it monthly, or subscribe to its RSS with the product filters set.
- It does not replace the announcements your Community Managers post for the platform you are reading this on. Those are on the Community, not in the table.
What I would change tomorrow if I were Atlassian
A "since" filter and a per-org note on Impact ("this affects sites with X") would turn the table back into a digest without losing the data. Until then, the fifteen minutes is the price of knowing.
Thank you to Mia for the sentence this article is built on. If your filter is different, put it in the comments; I will fold the good ones into the routine.
Verified against What's new across Atlassian and the retiring weekly page on 29 September 2026.
