POST /rest/api/3/search/approximate-count — intermittent 10–30s latency in production

[Alejandro Enrique Marín Astorga _CL_]

Context:
We use the Jira Cloud REST API v3 with a service account (Basic Auth) to power an internal support portal. When loading the "My Tickets" page, we perform 3 parallel calls to POST /rest/api/3/search/approximate-count to display counters in the sidebar (open, closed, created).

The issue:
Since May 20, we’ve been seeing intermittent response times of 10 to 30 seconds on approximate-count requests.

JQL pattern we use:

project = "HELPME" AND (
(reporter = "accountId1")
OR (cf[10023] = "accountId1")
OR (cf[10615] = "xxxxxxxxxx")
) AND statusCategory != Done

Questions:

1. Does approximate-count have a separate or stricter quota/rate limit compared to POST /rest/api/3/search/jql? Is this documented anywhere?
2. Does querying against a non-indexed custom text field in approximate-count JQL cause a full index scan? Is there any way to verify whether cf[10615] is indexed for JQL in our instance?
3. If we make 3 parallel approximate-count calls within the same second, do they count as a single quota unit or as 3 separate requests?
4. What is the recommended alternative for obtaining accurate issue counts efficiently at scale (thousands of issues) without using approximate-count?

[Ajay _view26_]

Hi @Alejandro Enrique Marín Astorga _CL_ 

The approximate-count endpoint shares the same burst-based rate limiting as other REST API endpoints — since March 2026, Atlassian has been enforcing the new points-based rate limit system alongside the existing burst limits.

Three parallel calls from the same service account to the same endpoint do count separately against the burst bucket.

If you're seeing the 10–30s delays rather than 429 errors, it's more likely server-side query execution time than rate limiting (rate limiting would return a 429 with Retry-After headers, not a slow 200).

A practical approach that might help:

• Instead of three parallel approximate-count calls with different JQL, try combining them into a single JQL query and using status categories or labels to differentiate counts client-side.