Issue Summary

Atlassian Cloud is enforcing new points-based API rate limits from March 2, 2026. Under this model, each app (Forge, Connect, OAuth 2.0 3LO) has an hourly points quota. When an app exhausts its quota, all API requests from that app are blocked until the next hourly reset - there is no partial throttling.

As a tenant admin, there is no way to:

• See which apps are consuming API quota on your instance

• Monitor how close any app is to being rate limited

• Identify which app has been rate limited after the fact

• View historical API consumption trends per app

The only observability exists in per-response HTTP headers returned to the calling app. Tenant admins are completely blind to API consumption across their instance. 429 rate limit responses are not captured in the Atlassian Admin audit log.

This has already been raised by other org admins in the Atlassian Community (Reminder: Please ensure your Apps comply with Jira Cloud Burst API rate limit) with no resolution.

Why This Matters

When an app is rate limited in Atlassian Cloud, the impact is not limited to background API calls failing silently. Depending on the app, rate limiting can cause:

• User-facing functionality to break - Marketplace apps that render UI components, macros, or panels via API calls will fail for all users when rate limited

• Automation pipelines to stall - Any app driving workflow automation (transitions, notifications, syncs) will stop processing until the hourly reset

• Data synchronisation to fall behind - Integration apps syncing with external systems (ServiceNow, Azure DevOps, etc.) will accumulate a backlog that compounds each hour

• Cascading failures - Apps with poor retry logic may enter retry storms that consume their entire next-hour quota immediately on reset

The tenant admin is the person accountable for service availability to their user base. Without observability into API consumption, they cannot:

1. Proactively identify risk - An app trending toward its quota limit could be addressed before it's rate limited

1. Triage incidents - When users report "the app stopped working," the admin has no way to determine if rate limiting is the cause without raising an Atlassian support ticket

1. Make informed vendor decisions - No data exists to compare API efficiency across apps performing similar functions

1. Plan capacity - No way to assess whether current app usage patterns are sustainable as user counts grow

Suggestion

1. Tenant Admin API Consumption Dashboard

Provide a dashboard in admin.atlassian.com showing per-app API consumption for the tenant. This should include:

• Current hourly points consumption per app (against their quota)

• Percentage of quota consumed per app

• Historical consumption trends (hourly, daily, weekly)

• Rate limit events - when an app was rate limited, for how long, and how many requests were blocked

• Identification of which quota tier each app is operating under (Global Pool vs Per-Tenant Pool)

2. Rate Limit Event Audit Logging

Include rate limit events (HTTP 429 responses) in the Atlassian Admin audit log. Currently these are not captured - the audit log shows HTTP 200 even when the app received a 429. Each audit entry should include:

• The app that was rate limited

• The timestamp

• The quota tier and remaining points at time of limiting

• The endpoint that triggered the limit

3. Alerting / Notification

Provide configurable alerts for tenant admins when:

• An app exceeds a configurable percentage of its hourly quota (e.g., 80%)

• An app is actively being rate limited

• An app has been rate limited repeatedly over a defined period

4. REST API for Consumption Metrics

Expose API consumption data via REST API so that tenant admins can integrate with their own monitoring and alerting platforms (Datadog, Splunk, PagerDuty, etc.):
 
 GET https://api.atlassian.com/admin/v1/orgs/\{orgId}/sites/{siteId}/api-consumption
Response should include per-app consumption data for the current and recent hourly windows.

Enterprise Use Case

Example Enterprise Cloud customer (20,000+ users, Confluence Cloud and Jira Cloud with Guard Standard) with multiple Marketplace apps installed. Environment includes apps that drive:

• User-facing Confluence macros and Jira panels

• Automated workflow processing

• External system integrations

• Bulk data operations

If any of these apps is rate limited, the impact ranges from degraded user experience to broken business processes. Currently have no way to detect or anticipate this. Only option is reactive - wait for users to report problems, then raise an Atlassian support ticket to determine if rate limiting was the cause.

With enforcement starting March 2, 2026, this observability gap becomes an operational risk for every enterprise Cloud customer with Marketplace apps installed.

Workaround

There is no known workaround. Tenant admins cannot access API consumption data for apps running on their instance.

The only available action is to raise an Atlassian support ticket after an incident has already occurred.

References

• Rate limiting - Jira Cloud platform - Current rate limiting documentation (developer-facing only)

• Rate limiting - Confluence Cloud - Confluence equivalent

• Scaling responsibly: evolving our API rate limits - Atlassian blog announcing the new model

• Community thread: Apps comply with Jira Cloud Burst API rate limit - Org admins raising the same observability gap

• API Access REST API - Existing org-level API token observability (does not cover consumption metrics)