Genesys Cloud - Main

Hey everyone,

I've noticed a few agents are showing up as 'not responding,' even though their auto-answer are set up.

#Telephony

------------------------------
ANA BELEN ALONSO VIDALES
CTI
------------------------------

Hi Ana

The "Not Responding" status is caused when an agent does not answer the interaction before the timeout threshold is reached.  This can also be caused by connectivity issues.

Common Causes and Solutions:

• Declined/Missed Calls: The agent missed the alert.
• Multiple Sessions: The agent is logged in on multiple tabs, browsers, or devices.
• Network Interruption: Unstable internet (VPN/proxy) causes WebRTC or WebSocket disconnections.
• Audio Issues: Headset switching or WebRTC "flapping" during an inbound call.
• Browser Issues: High CPU usage, browser extensions, or putting tabs to

Have you done any diagnostic tests and confirmed the results?  I would also suggest to enable the network/console logs as this might be helpful in finding the root cause.

Hope this helps.

Regards

------------------------------
Stephan Taljaard
EMBEDIT s.r.o
------------------------------

Hi Ana,

Adding to the points already mentioned, even with Auto Answer enabled, the client still needs to successfully negotiate the WebRTC connection. If there are issues such as microphone permissions, network instability, or WebRTC connectivity, agents can still end up in Not Responding.

It may also be worth checking the WebRTC troubleshooter and network readiness test for the affected users.

------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------

Hi

I will review all your recommendations.

Today, I've reviewed the following case: once again, an agent with an active automatic response has been in "not responding" status from Friday at 9 PM until today. Until now, I hadn't detected this type of case, and I'm not sure I fully understand how it's working.

Regards

------------------------------
ANA BELEN ALONSO VIDALES
CTI
------------------------------

Original Message:
Sent: 04-20-2026 05:34
From: Phaneendra Avatapalli
Subject: NOT RESPONDING

Hi Ana,

Adding to the points already mentioned, even with Auto Answer enabled, the client still needs to successfully negotiate the WebRTC connection. If there are issues such as microphone permissions, network instability, or WebRTC connectivity, agents can still end up in Not Responding.

It may also be worth checking the WebRTC troubleshooter and network readiness test for the affected users.

------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------

Hi Ana,

Looking at the timeline, my understanding is that the Alert event may not have cleared down properly for the agent, which could explain why they ended up in Not Responding even with Auto Answer enabled.

It may be worth checking browser/network logs or the WebRTC troubleshooter for the affected agent, and as a quick check, asking them to go Off Queue and back On Queue to see if the state clears.

Hope someone from community might add more if they have seen similar behaviour.

------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------

Original Message:
Sent: 04-20-2026 06:18
From: ANA BELEN ALONSO VIDALES
Subject: NOT RESPONDING

Hi

I will review all your recommendations.

Today, I've reviewed the following case: once again, an agent with an active automatic response has been in "not responding" status from Friday at 9 PM until today. Until now, I hadn't detected this type of case, and I'm not sure I fully understand how it's working.

Regards

------------------------------
ANA BELEN ALONSO VIDALES
CTI
------------------------------


Original Message:
Sent: 04-20-2026 05:34
From: Phaneendra Avatapalli
Subject: NOT RESPONDING

Hi Ana,

Adding to the points already mentioned, even with Auto Answer enabled, the client still needs to successfully negotiate the WebRTC connection. If there are issues such as microphone permissions, network instability, or WebRTC connectivity, agents can still end up in Not Responding.

It may also be worth checking the WebRTC troubleshooter and network readiness test for the affected users.

------------------------------
Phaneendra
Technical Solutions Consultant

Hi ANA

Also, complementing what was said, what you can do is create a trigger based on the "users...activity" event when the status "routingStatus.status = NOT_RESPONDING" is identified.
Create a workflow that will call an API to return the agent to the "on queue" status.

------------------------------
Kaio Oliveira
GCP - GCQM - GCS - GCA - GCD - GCO - GPE & GPR - GCWM

PS.: I apologize if there are any mistakes in my English; my primary language is Portuguese-Br.
------------------------------

Hi Ana, 

We see this same behavior, even for agents that have auto-answer enabled and persistent connection turned on.  It's very hard to troubleshoot because there isn't anything from a log perspective that gives us insights as to "why".

Here's an idea out there for the Platform to provide a clearer description of what actually might be going on:
https://genesyscloud.ideas.aha.io/ideas/OPGCV-I-148

------------------------------
Peter Stoltenberg
Engineer
------------------------------

Thanks for the idea.

Right now I suspect  that these agents the %idle value is also confusing. I believe the data is calculated on the "total ACD routing" instead of "On queue" time.

It's being counted as "active time" even when the only state is "not responding". Would you consider that correct?

Regards

------------------------------
ANA BELEN ALONSO VIDALES
CTI
------------------------------

Original Message:
Sent: 04-21-2026 11:59
From: Peter Stoltenberg
Subject: NOT RESPONDING

Hi Ana, 

We see this same behavior, even for agents that have auto-answer enabled and persistent connection turned on.  It's very hard to troubleshoot because there isn't anything from a log perspective that gives us insights as to "why".

Here's an idea out there for the Platform to provide a clearer description of what actually might be going on:
https://genesyscloud.ideas.aha.io/ideas/OPGCV-I-148

------------------------------
Peter Stoltenberg
Engineer
------------------------------

Hi Ana,

I've come across something that may be applicable or may not be applicable to you, but it turned out to be the issue for us. We've spent the last month trying to review what was going on from a technical perspective. Our IT Desktop tool showed us nothing clear. Network health look good. We were so stumped.

Now, in parallel, we've had agents report "genesys was freezing" on them. Same review from our team: all hands on deck reviewing at logs, trying to understand what was going on. We watched a few screen recordings (we just recently turned it on), and found that agents had a Dashboard up; either split screen or in full mode as they were waiting for calls to be delivered to them. 

I recalled that those dashboards are all real-time subscriptions.., and started thinking through how many web socket connections were being created, and how much data was being streamed to these users, via the WS connection. So, I asked the most frequent offending agent of the Not Responding and the Genesys Freezing to stop using that dashboard. and just hang out in the Agent workspace.

That fixed all their problems.  No More not responding, no More Freezing. 

Thanks,

Peter

------------------------------
Peter Stoltenberg
Engineer
------------------------------