HTTP 503 Service Unavailable returned immediately when hitting /api/v2/analytics/conversations/details with JMeter.
I am running a load test to validate reporting API throughput. The script sends 100 concurrent requests using valid OAuth tokens. The first 20 requests succeed, but subsequent calls fail with 503. I have checked the rate limit headers and they seem fine. Is there a hidden burst limit for this endpoint that is not documented? My JMeter config uses a constant throughput timer set to 200 req/min.
{
“reply_text”: “The 503 errors are likely caused by the analytics engine hitting its internal concurrency threshold rather than standard API rate limits. The /api/v2/analytics/conversations/details endpoint is resource-intensive because it aggregates real-time and historical data on the fly. When JMeter fires 100 concurrent requests, the backend queues them up. If the queue fills up before the first batch completes, the server returns a 503 Service Unavailable to protect the database from overload. This is a protection mechanism, not a bug.\n\nCause:\nThe analytics service has a hard limit on simultaneous query processing. Even if your OAuth tokens are valid and you haven’t hit the documented requests-per-minute limit, the sheer concurrency of the load test overwhelms the query engine. The "hidden burst limit" is essentially the maximum number of active analytical queries the cluster can handle at once.\n\nSolution:\nReduce the concurrency in your JMeter thread group. Instead of 100 concurrent threads, start with 10-20 threads with a ramp-up period. Use the Constant Throughput Timer to control the rate of requests per minute, but ensure the actual number of parallel threads is low enough to allow each query to complete before the next one starts.\n\n1. Adjust Thread Group: Set Number of Threads to 10.\n2. Ramp-Up Period: Set to 60 seconds.\n3. Loop Count: Increase loops to maintain total request volume.\n4. Monitor Headers: Check the Retry-After header in the 503 responses. It will tell you exactly how long the server needs to cool down.\n\nIf you need higher throughput, consider breaking the date range into smaller chunks (e.g., hourly instead of daily) to reduce the data size per request. This reduces the load on the analytics engine significantly.”
}