Atlassian API Rate Limits: What Changed and What It Means for Reporting Dashboards

Atlassian has introduced enforced points-based API rate limits across Jira Cloud. These limits apply to all Marketplace apps that integrate with Jira Cloud using Forge, Connect, or OAuth 2.0 (3LO), regardless of how the app is built, what it does, or whether it is free or paid. This includes Performance Objectives app.

The goal, based on Atlassian’s announcement of this change, is to protect Atlassian’s infrastructure from traffic spikes and ensure stable performance for all customers.

What Changed on Atlassian’s Side

Atlassian now limits how much data an app can retrieve:

• Per Jira instance

• Per app

• Per minute and per hour

The limits are enforced based on the actual workload generated by API requests (for example, how many issues are returned), not just the number of requests.

This means that apps which request large datasets or make many simultaneous requests are more likely to hit these limits.

In Performance Objectives gadgets, this message is displayed when API rate limits are reached:

Open

How API Rate Limits Affect Users with Large Jira Dashboards

In large Jira instances, dashboards often contain:

• Many reporting gadgets

• Each gadget querying thousands or even tens of thousands of work items

For large dashboards containing many gadgets that each load substantial data sets, hitting the Atlassian API rate limits can temporarily prevent gadgets from loading. As a result, all users will be blocked from using the app until the rate limit resets.

Previously, all Performance Objectives' gadgets on a dashboard loaded simultaneously, which could generate a very large burst of API traffic in a short time. Under the new Atlassian limits, this behavior could result in API request rejections, which required a change in how gadgets load data.

How Performance Objectives for Jira Adapts

To comply with Atlassian’s enforced limits and ensure reliable dashboard loading, we’ve changed how our gadgets work:

1. Sequential Gadget Loading

Gadgets now load one after another per user, instead of all at the same time.

• This prevents traffic spikes that could exceed Atlassian’s API limits.

• You may see a gadget showing “Awaiting priority queue” message. This simply means another gadget is currently loading.

• Gadgets may also wait if another dashboard (or browser tab) is already loading data.

Open

2. Data Caching

We’ve added a caching layer to reduce repeated real-time API calls:

• After the first successful load of a gadget, report data is cached.

• As a result, revisiting or refreshing a dashboard loads much faster.

• Each gadget shows how long ago the data was last refreshed.

To get fresh data, users can manually refresh individual gadgets by clicking the Refresh icons on the gadget. This gives them control over which reports pull new data and when.

Open

Open

What This Means for Performance Objectives Users

For our app users, these changes mean that dashboards will be more reliable, with fewer failed loads caused by API rate limits.

After the initial load, performance will generally improve thanks to caching, so revisiting or refreshing a dashboard is faster. Users also gain more control over their data, as individual gadgets can be refreshed on demand rather than all at once. On the other hand, dashboards with many gadgets may take slightly longer to load initially, because gadgets now load sequentially rather than in parallel to avoid overwhelming the Jira API.