We are running load tests for a new contact center deployment and observing unexpected WebSocket disconnections when multiple agents initiate screen recording simultaneously. The environment uses Genesys Cloud Engage with the latest Web SDK (version 2.14.0).
The issue occurs when we simulate 500 concurrent agents starting screen recordings within a 60-second window. Approximately 15% of the sessions fail with a 1006 close code shortly after the startScreenCapture method is called. The API logs show successful initial handshake responses from the /api/v2/recordings/screens endpoint, but the persistent connection drops before the first chunk of data is transmitted.
We have verified that our network infrastructure supports the required bandwidth, and the error does not occur when the load is reduced to 100 concurrent sessions. This suggests a potential limit on the number of simultaneous WebSocket connections per organization or a rate-limiting issue on the recording service endpoints.
Has anyone encountered similar behavior during load testing? We are trying to determine if this is a known limitation of the screen recording service under high concurrency or if we need to adjust our connection retry logic. Any insights on the maximum supported concurrent screen recording sessions per organization would be helpful. We are currently planning for a peak load of 2,000 agents and need to ensure the recording service can handle this scale without significant drop rates.
I see you are diving deep into the SDK and WebSocket close codes. That sounds like a serious infrastructure headache! As a supervisor managing a team of 30, I don’t touch the code, but I know exactly what happens to my agents when their sessions drop. It kills their flow and spikes their after-call work time.
While the developers here are likely debugging the 1006 close code, I want to highlight the operational impact we see on the floor. When screen recording fails mid-interaction, our agents lose the visual context they need to guide customers. This leads to longer handle times and lower CSAT scores.
From a coaching perspective, I’ve found that the best mitigation isn’t just fixing the code, but changing how we monitor the queues during high load. I recommend setting up a real-time dashboard alert for “Session Interruptions” or “Technical Errors” in the Agent Analytics view. When that metric spikes, we can immediately pause new interactions in that specific queue to prevent further failures.
Also, ensure your agents have a clear, one-click fallback process. If the screen share drops, they should know exactly which button to click to re-establish the connection without restarting the entire call. We drilled this into our team last week, and it reduced the average recovery time by 40%.
Keep us posted on the technical fix! We are eager to get back to stable, high-quality interactions. Our agents are ready to perform, but they need the tools to stay connected. Let’s get those WebSockets stable so we can focus on what really matters: helping our customers.