My configuration keeps failing… Running JMeter with 50 threads hitting GET /api/v2/analytics/queues/details. The response returns HTTP 503 Service Unavailable after 10 seconds.
Is there a hard limit on concurrent analytics requests for new tenants?
This looks like rate limiting rather than a hard tenant cap. The 503 indicates the analytics service is overloaded. Try reducing thread count or adding X-Genesys-Rate-Limit headers to monitor usage. Also, check if GET /api/v2/analytics/queues/details is the correct endpoint for bulk data, as it might be slower than expected.
make sure you are not hammering the analytics api directly during load tests. the 503 is a symptom, not the cause. you are bypassing the standard rate-limit headers and hitting the backend aggregation engine with raw concurrent requests. this triggers circuit breakers.
the endpoint /api/v2/analytics/queues/details is designed for interactive dashboard queries, not bulk extraction. it calculates real-time aggregations. under load, this exhausts the compute resources allocated to your tenant’s analytics tier.
check your terraform state for the genesyscloud_analytics_report resources. if you are trying to replicate this data, use the scheduled report api instead. it queues the job and returns a pollable url. much safer for automation.
resource "genesyscloud_analytics_report" "queue_load_test" {
name = "Queue Details Bulk"
schedule {
run_once = true
start = "2023-10-01T00:00:00Z"
}
report {
type = "queue"
filters {
queue_ids = ["all"]
}
time_group {
type = "hour"
offset = "+10:00" # aedt
}
metrics = ["acd_wrapup_time", "acd_hold_time"]
}
}
also, verify the x-genesys-rate-limit headers in your jmeter sampler. if you see retry-after, implement exponential backoff. do not just increase threads. the analytics store has a hard cap on concurrent aggregations per tenant. exceeding this causes transient 503s that cascade.
for digital channels, the limit is lower. if your queue includes webchat or email, the aggregation is heavier. consider splitting the test into voice-only and digital-only segments. this isolates the bottleneck.
finally, check the genesyscloud_integration_cxaas configuration. if screen recording is enabled, it adds metadata overhead to every session. this slows down the analytics pipeline significantly. disable it for the test environment if possible.