The Jira API rate limit in Jira Cloud is three separate limits running at once: an hourly points quota, per-second burst limits per endpoint, and per-issue write limits. The default global pool is 65,000 points an hour, GET and POST default to 100 requests a second, and one issue takes 20 writes per 2 seconds.
Three limits, all at the same time
Most APIs give you one number. Jira Cloud's got three, and Atlassian's clear that they're independent and enforced together. You can be well under one and still be stopped by another. When any of them is exceeded, Jira returns HTTP 429 Too Many Requests, and your app should respect the Retry-After header.
| Item | Limit | Applies to |
|---|---|---|
| Hourly points quota, Tier 1 global pool | 65,000 points per hour, shared across all tenants | Default for all apps |
| Per-tenant quota, Standard edition | 100,000 + 10 points per user per hour, capped at 500,000 | Apps assigned to the per-tenant pool |
| Per-tenant quota, Premium edition | 130,000 + 20 points per user per hour, capped at 500,000 | Apps assigned to the per-tenant pool |
| Per-tenant quota, Enterprise edition | 150,000 + 30 points per user per hour, capped at 500,000 | Apps assigned to the per-tenant pool |
| Default burst limit, GET and POST | 100 requests per second | Per endpoint, per tenant |
| Default burst limit, PUT and DELETE | 50 requests per second | Per endpoint, per tenant |
| Writes to a single issue | 20 per 2 seconds and 100 per 30 seconds | Create, update and delete on one issue |
How each system counts
The hourly points quota
Every request starts with a base charge of 1 point, plus points for each object it returns. Core objects such as issues and projects count 1 point each to read. Identity objects such as users and groups count 2 points each. Write requests are charged only the base amount.
So a search that returns 50 issues uses 51 points, while an update to one issue uses 1. Reads that pull back lots of users drain the pool twice as fast. The default Tier 1 global pool is one shared 65,000 points per hour across all tenants, and quotas reset at the top of each UTC hour. Apps on the per-tenant pool get a quota worked out from the edition and user count, up to a cap of 500,000.
Burst limits per endpoint
Burst limits use a token bucket for each endpoint and each tenant, and they don't depend on how many users the site has. The default steady state is 100 requests per second for GET and POST, and 50 for PUT and DELETE.
Writes to one issue
A single issue won't take more than 20 write operations per 2 seconds and 100 per 30 seconds. That matters for automations that update the same issue in a loop, such as syncing fields from another tool one at a time.
Why staying under 100 a second isn't enough
Atlassian Developer documentation is clear that the hourly points quota and the per-issue write caps apply on top of the burst limit. An endpoint can also carry its own custom limit. The docs give the example of 5 requests per second on one Service Desk customer endpoint, which will throttle you far below the 100 per second default. Check the endpoint's own docs before you set your pacing.
Who the points system applies to
The points-based and tiered quota limits are now enforced for Forge, Connect and OAuth 2.0 (3LO) apps. API token-based traffic isn't affected by the points change and stays governed by the existing burst limits. If you run a simple script with an API token, the burst and per-issue limits are the ones to plan for.
Building a client that copes
- Read Retry-After on every 429 and wait that long before trying again.
- Request only the fields and objects you need, because every object returned adds points.
- Batch writes to one issue rather than firing many small updates in a row.
- Watch for the top of the UTC hour if you're close to the points quota.
If you can, react to changes instead of polling for them. My explainer on how APIs and webhooks differ covers when each fits.
How Asana and Linear compare
Asana sets limits per authorisation token in one-minute windows, 150 requests per minute on Free domains and 1,500 on others, as of Nov 2026. Linear uses a leaky bucket algorithm, discourages polling in favour of webhooks, and returns up to 50 records per page by default.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
My advice for anyone integrating with Jira Cloud
Plan for all three limits from day one, not just the burst number, because that's the one people remember and it's rarely the one that bites. Keep reads lean, especially on users and groups, space out writes to any single issue, and treat a 429 as a pause rather than a failure. And log every 429 you get. A good API monitoring tool will tell you which limit you're hitting long before your users start complaining.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
What status code does Jira return when I hit a limit?
HTTP 429 Too Many Requests, with a Retry-After header.
Do reads and writes use the same points?
No. Reads add points per object returned; writes are charged only the base 1 point.
Does the quota reset?
Points quotas reset at the top of each UTC hour.
Does the points system apply to API tokens?
No. Atlassian says API token traffic stays under the existing burst limits.
Can I update one issue rapidly?
Up to 20 writes per 2 seconds and 100 per 30 seconds on one issue.
