I understand the need for a fair rate limit system, and I prefer the new simplified HTTP headers for the point-based system over the previous ones. I also don’t want to encourage anyone to exploit the new limits to compromise other apps. However, there are clear flaws in the point-based rate limit system that have been raised multiple times in 2026 point-based rate limits at the end of last year, and Atlassian has not really addressed them yet.
I’ve created a simple Confluence app (Tier 1) that fetches 250 pages when the user clicks a button (one API request). It takes only about 3 minutes for a single user to exceed the global quota by clicking the button repeatedly, rendering the app unusable for up to one hour on all tenants. The fact that the quota always resets at the top of the hour makes this new attack vector even easier to exploit.
Here’s a video demonstrating how easy it is to lock out other tenants:
According to a response from Atlassian in the community thread, the rate limit system is supposed to handle this scenario to prevent lockouts. However, it doesn’t seem to be functioning, at least not for my test app.
The hourly quota is intended as an accounting boundary, not as a guarantee that an app will be unavailable for a full hour if a spike occurs. The model will forgive occasional hourly spikes for the app; however, when the app consistently crosses the Global Pool thresholds, please explore optimizing API usage patterns. […] A design that results in hour-long lockouts for apps would not be acceptable, and this is one of the key scenarios we’re pressure-testing during this period before enforcement.
Upgrading the app to Tier 2 would reduce the lockout risk, but even Tier 2 apps can become unusable within a tenant for up to an hour if just a single user repeatedly triggers a somewhat complex action through the app UI.
How are app vendors supposed to handle this risk, given the short timeline for the rollout of the point-based rate limit system?