Download the RC from our site to start testing your app for compatibility with the changes. Be sure to take a look at our Preparing for Confluence 11.0 guide to find out what you need to do to make your app compatible. We’ll update that page regularly, so keep an eye on it to see any changes.
Reminder: for future release updates, make sure you visit the Atlassian changelog, and consider subscribing to the RSS feed.
The response to the request to our apps REST controller is as follows: message: "Rate limit exceeded."
I didn’t make changes to the rate limiting configuration. But it seems the default configuration might be too strict. I don’t know how rate limiting exactly works and if its configured per endpoint or in general. But as said. Having the same macro on a page multiple times is not unusual and the default rate limiting should yet appy in my opinion.
We are using “com.atlassian.confluence.user.UserVerificationTokenManager” inside one of our Confluence DC apps (such as user password resets and secure verification workflows). Now it seems UserVerificationTokenManager is hidden from the OSGI.
Could you please reconsider exposing a public, supported interface for UserVerificationTokenManager (or providing an equivalent public service component) to the OSGi container in Confluence Data Center?
Alternatively, if token management has been intentionally moved behind a new public API layer or service in Confluence 11.0, could you point us toward the correct public documentation or service interface we should be using instead?
Hi Cederic! Yes, in 11.0 rate limiting is enabled by default. You can find more details about it here: Improving instance stability with rate limiting | Confluence Data Center 10.2 | Atlassian Documentation - What kind of traffic are you seeing? What endpoints are being limited? We added the ability to rate limit individual endpoints for plugin vendors, however the global configuration mentioned above is most likely your cause, as the effective limit is the lower of the two configurations.
The endpoints being limited were the ones from our plugin.
However, today, I can’t seem to reproduce the issue.
Very strange. I’ll get back to you if I can reproduce the issue some point.
Hey @ephillips, could you also bring back com.atlassian.confluence.search.v2.score.ScoreFunctionFactory please?
It’s needed by some of our apps. Looks like the bean still exists but isn’t exposed anymore in RC1 (have not checked RC2 yet).
@ephillips We have noticed an issue making our app compatible.
We would like the log4j2 org.apache.logging.log4j.core package to be available as it is in Jira 9.5+ and bamboo 9+. We use this for helping users troubleshoot configuration of our app and to make it easier to create support logs for the administrators when they have a problem with our app.
Hi GeneCulling,
Thanks for raising this. We deliberately don’t export org.apache.logging.log4j.core in Confluence 11.0. It exposes the whole logging configuration (appenders, output destinations, and so on) to apps, which is a security risk. Apps can still log through SLF4J or the Log4j 2 API.
11.0 has just shipped on 8 October 2026, so this won’t change in 11.0. We’ll discuss this internally and decide whether to include it for the next release. In the meantime, administrators can change your app’s log levels in General Configuration > Logging and Profiling or in log4j2.xml. Your app’s logs are included in the support zip.
It would help us to know exactly what your app needs from the core package, for example changing log levels or finding log file paths.
For our test login we create a custom appender with logging set to debug for our packages so that we can write all of the relevant details to a screen, it shows the steps taken and key information, also allowing for the user to review the specific details about the login attempt and makes the information easy to review before sending it to us if they need further help.
Once the test login is done, we set logging for our package back to the level it was at before, preventing excess logging.
