Stumbled on a weird bug today with our digital messaging flow. The wait time metric in the performance dashboard spikes to 45 seconds, yet the queue depth shows zero. The flow logic seems correct:
routing:
strategy: longest_available_agent
timeout: 30s
Is there a known delay between the message entering the queue and the metric update? We are using the latest Architect version in the eu-west-1 region. Any insight into this latency would be appreciated.
You need to check the queue configuration for the digital channel. The wait time spike with zero depth usually means the metric is capturing the time spent in the pre-queue validation or the skill group matching logic before it even hits the routing strategy. Review the flow steps immediately preceding the queue node.
Have you tried monitoring the WebSocket handshake latency during the ramp-up phase? The suggestion above about pre-queue validation is valid, but in my recent JMeter tests, I noticed that high concurrent connection attempts can cause the platform API to throttle incoming message events, creating an artificial delay before the message actually hits the queue logic. If the throughput hits the rate limit for your org tier, the messages get buffered on the client side or by the edge proxy, which inflates the wait time metric while the queue depth remains zero because they haven’t officially entered the queue yet. Try adding a constant throughput timer in your load test script to space out the message submissions and see if the spike disappears. It might not be an Architect flow bug, but rather a capacity ceiling on the ingestion endpoint.