Check out the new Confluence Cloud Changelog

Last week we published a new page in the Confluence Cloud Developer Docs. The new Changelog page is published under a new section called Release Notes.

This page will be the central source of truth for the following changes that may affect apps and integrations built for Confluence Cloud:

  • New features
  • Changes
  • Deprecations
  • Product updates

When you’re looking for what’s changed in Confluence Cloud, we recommend looking here first.

One of the things we’ve heard from you is that you would like to be notified when a change occurs. While we don’t have a subscribe feature on the changelog page at this time, we have committed to crosspost these updates to a dedicated category on the Developer Community. This will allow you to “watch” the forum or subscribe to its RSS feed to be notified even faster.


Awesome!!! :slight_smile:

1 Like

Thanks, that helps a lot.

1 Like

So… Jira version next week?


LOL, on the confluence planning page of these comms was a list of expected questions. This was one of them. Jira Cloud versions are being planned. I’m currently documenting what we did to get this up and working (it’s more than just putting up a page, it’s having the support to make sure these updates get placed up there). So we’re working on this yes and hope to have Changelogs up for all of our Cloud products soon.


This is very exciting and encouraging. Thank you!


BTW, you can subscribe to RSS feeds in Slack…

/feed subscribe

I’m still hopeful for this but it doesn’t seem to be tracking dates that things are actually rolled out accurately? Is it tracking?

Knowing the plans ahead of time are great!


Hey @rwhitbeck,

Firstly I think this is awesome and exactly the kind of thing all vendors appreciate and are hoping for more of.

Does this changelog track with every Confluence API change (even what you might consider small bug fixes?)

Does this system have any automated component or is it all manual?

There is definitely already a ton of great info here.

It would be helpful I think if the ‘announcements’ currently displayed of upcoming changes (which are awesome) are linked to entries when things actually get deployed both first to EAP instances and then live.

Of course we all know once a rollout is initiated it can take many hours to complete, but knowing those exact start times would be very helpful and meaningful.

For instance with the recent Search REST API rollout…no vendors or customers (probably including much of Atlassian) knew that those changes were actually rolling out after vendors reported detected and reported the breaking changes. At least we would have known it had gone out.

Also the rollouts could have a ‘status’: green or delayed or cancelled or deployed. If we see something breaking and status is still green we’d know either no one at Atlassian has seen it or its being deployed with new known bugs. Either bit of information is helpful.

Do you disagree with the value of any of the above? Perhaps there are better ways? It feels to me like this is both genuinely helpful as is, but in current incarnation more of an ‘announcement’ board than a changelog?

Feel free to educate me on those interpretations! (Honestly!)

Also another genuine question: Are rollbacks of deployments recorded here (or will be) when they happen?

Again this is great, but we are trying to understand the true scope and coverage currently and planned.



Right now it’s all manual. It’s not as complete as we’d like. There are some efforts to make it automated.


Makes sense!

Is there any kind of deployment log we could have access to, even if it doesn’t detail everything?

I’m confident that exists , though I realize there might be multiple teams deploying to the Connect+REST API platforms impacting vendors so it’s possible those are multiple deployment logs. (At least that is my understanding from what I’ve been told.) Still that would be very helpful.

What a great little but meaningful Connect or Forge app that could be! One that surfaces to app devs changes impacting them.

That stuff will ultimately need be centralized and shared out anyway one way or another for the Enterprise Cloud offerings to really have a chance of approaching the SLAs I’m hearing about.