Right, so this has been driving me mental for two days and support has been zero help so far.
We are in the ap-southeast-2 (Sydney) region. Our overnight ETL job pulls conversation details via POST /api/v2/analytics/conversations/details/query for the previous 24 hours. The job runs at 02:00 AEST daily.
Starting last Thursday, the query results are missing conversations that I can clearly see in the Genesys Cloud admin UI. Specifically, conversations that ended between 23:00 and 23:59 AEST are not appearing in the API response. They show up eventually - but not until about 04:00 AEST, roughly 4-5 hours after the conversation ended.
The query filter uses interval set to the previous calendar day in ISO 8601 format:
{
"interval": "2025-05-13T00:00:00.000+10:00/2025-05-14T00:00:00.000+10:00",
"order": "asc",
"orderBy": "conversationStart",
"paging": { "pageSize": 100, "pageNumber": 1 }
}
This was rock solid for eight months. Nothing changed on our end. No SDK upgrade, no filter changes, no new queues. The conversations are not stuck in an active state either - they show as disconnected and wrapped up in the UI.
Anybody in APAC seeing the same lag? Is there a known analytics pipeline delay happening?
This is almost certainly related to the analytics data pipeline replication lag that Genesys quietly acknowledged on their status page for ap-southeast-2 starting around May 8th. The status page showed “degraded performance” for the Analytics API for about 72 hours, but the underlying issue - increased write latency on the analytics data store - has been causing a tail latency problem ever since.
What is happening technically is that the analytics pipeline processes conversation events asynchronously. When a conversation ends, the finalized record gets written to the analytics data store with some delay. Under normal conditions, that delay is under 60 seconds. During the degraded period, conversations ending during peak hours (which for APAC overlaps with US morning traffic on the shared infrastructure) are taking 2-5 hours to become queryable.
There are two tactical workarounds:
-
Shift your ETL window. Instead of querying at 02:00 AEST for the previous day, query at 06:00 AEST for two days ago. This gives the pipeline a full 30+ hours to settle.
-
Use the POST /api/v2/analytics/conversations/details/jobs endpoint instead of the synchronous query. The async jobs endpoint queries from the fully replicated data store rather than the near-real-time index, so it consistently returns complete results even during pipeline degradation.
The trade-off with the async jobs endpoint is latency - you submit the job, poll for completion, then download the results. But for a nightly ETL, that 2-3 minute overhead is negligible.
Saw the same thing during a CXone-to-GC migration last month. The async jobs endpoint is the fix. One thing to note: the jobs endpoint has a different rate limit (5 concurrent jobs per org) compared to the synchronous query endpoint (10 requests per second).
If your ETL submits multiple parallel queries for different queues, you will need to serialize them when switching to the jobs API.
To add a monitoring dimension to this discussion: if you want to detect pipeline lag proactively rather than discovering it when your ETL results are incomplete, you can implement a canary check.
The approach is straightforward. Before your ETL runs, query for a single known conversation ID using GET /api/v2/analytics/conversations/{conversationId}/details. Pick a conversation that ended 2 hours before your ETL window. If that endpoint returns a 404, the pipeline has not caught up yet, and your ETL should back off and retry after 30 minutes.
We run this canary check in our Architect flows as well. Our after-hours IVR references a Data Action that pulls the latest queue statistics. When the analytics pipeline is lagging, the Data Action returns stale data, which causes incorrect queue-depth announcements to callers. The canary check allows us to fall back to a static announcement instead.