Statistics API returning stale queue counts during high-concurrency k6 test

Stuck on a problem and need help troubleshooting a discrepancy between real-time queue metrics and the /api/v2/analytics/queues/realtime endpoint.

I am running a k6 load test simulating 500 concurrent virtual users entering a single support queue. The goal is to validate that the waiting count increments correctly under load.

Here is the relevant k6 snippet fetching the stats:

import http from 'k6/http';
import { check, sleep } from 'k6';

export default function () {
 let res = http.get(`https://{{hostname}}.mypurecloud.com/api/v2/analytics/queues/realtime?interval=pt5s`);
 
 let waiting = res.json().items[0]?.metrics['waiting']?.value || 0;
 
 check(res, {
 'status is 200': (r) => r.status === 200,
 'waiting count > 0': (r) => r.json().items[0]?.metrics['waiting']?.value > 0,
 });
 
 console.log(`Time: ${new Date().toISOString()} | Waiting: ${waiting}`);
 sleep(2);
}

The issue is that the waiting metric lags by 15-20 seconds compared to the actual call volume injected by k6. During peak load, the API returns waiting: 0 even when I know 200+ calls are in the queue based on my script logs.

I have verified the OAuth token is valid and has the analytics:read scope. I also tried increasing the interval parameter, but it made the latency worse.

Is there a known caching layer or aggregation window for the realtime endpoint that I am missing? I need sub-second accuracy for my performance baselines.

Also, here is the error structure when the API times out under extreme load:

{
 "code": "BadGateway",
 "message": "The server encountered a temporary error and could not complete your request.",
 "status": 502
}

Any insights on tuning the request or using a different endpoint for true real-time observation?

if i remember correctly…
analytics endpoints are cached so they lag during k6 spikes. try the websockets api instead for real-time data.