Genesys Cloud - Main

This is one of the most common issues I've seen across different customer environments. The tricky part is that by the time troubleshooting begins, the issue has often resolved, making it difficult to capture useful evidence.

Some of the first things we usually check are:

• Browser console & network logs
• WebRTC diagnostics
• VPN/proxy or network stability
• Browser extensions
• CPU/Memory utilization
• VDI or remote desktop environments

Even after reviewing all of these, many cases still end up without a clear root cause because the issue is intermittent.

I'm curious to hear from the community:

• What has been the most common root cause in your environment?
• What logs or diagnostics do you always collect first?
• Any best practices that have helped reduce these incidents?

Looking forward to learning from everyone's experience!

#GenesysCloud #GenesysCommunity #Not_Responding#ContactCenter #WebRTC #Troubleshooting

#Omni-ChannelDesktop/UserInterface
#System/PlatformAdministration
#Telephony

------------------------------
Keshav Manhas
------------------------------

Hi Keshav,

Good topic. In our environment, most Not Responding cases are simply agents missing an interaction, although we have also seen cases related to network/connectivity issues.

One change that helped us was moving our WebRTC phones to persistent connection. Since making that change, we have seen a reduction in the network/WebRTC-related Not Responding occurrences.

From other Community discussions, there doesn't seem to be one single root cause either. People have reported issues related to unstable network/VPN connections, multiple active sessions, microphone or headset state, browser/tab suspension, WebRTC connectivity and station connection issues. There have even been cases where the eventual cause was concurrent station connection attempts rather than the network itself.

For intermittent cases, I think capturing evidence at the time of the issue is probably the most important part. We normally want the Conversation ID and exact timestamp first, followed by console/network logs and WebRTC diagnostics so they can be correlated with the Genesys Cloud-side logs if escalation is required.

Scheduled Log Capture and On-Demand Log Capture are also useful options when the issue is intermittent and difficult to reproduce.

Interested to hear what others are seeing and what their most common root causes have been, particularly whether persistent connection has made a noticeable difference in other environments as well.

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

Hello, @Keshav Manhas.

I've seen a lot of problems related to bad network connections, especially when users are connected to 2.4 GHz Wi-Fi or are too far from the network equipment.

Usually, the native WebRTC tester works really well for these cases, but sometimes we need some extra tools like Wireshark to take a deeper look at the customer's network.

Another common problem I've seen is related to browser translator tools. Here in Brazil, it's really common to see this feature enabled, and it can sometimes cause unexpected bugs in the Genesys Cloud interface.

Some browser settings can also generate this kind of issue, especially memory saver or energy saving features. It's always worth disabling them during troubleshooting to see if the behavior changes.

------------------------------
Raphael Poliesi
------------------------------

Hi Keshav

This is also my main pet peeve at the minute!

The biggest frustration is how difficult it is to catch. As you said, by the time an agent lets me know they have an issue, they're able to answer the next call.

Like Phaneendra, we also looked to move to Persistent Connection WebRTC. However, we found that some, not all of our agents, were then not being offered calls at all. From a ticket, Genesys appeared to indicate this was a STUN/TURN ICE negotiation issue. Our internal investigations concluded that all required ports were already open.

We get many symptoms reported including clicking answer many times but not doing anything, no answer button at all etc. Agents do also just genuinely miss calls and occasionally these get reported as technical problems annoyingly!

WebRTC Tester seems to always come back perfectly in order - it almost feels like pure chance that a call fails and if it were 10 seconds later the agent would answer it fine.

It affects agents in various offices, on WIFI and ethernet connections and also home workers.

I do have a ticket with Genesys open at the minute and the next step is to get a wireshark trace running on their machine.

Keen to hear everyone else's experience and if there's any further troubleshooting to try. Some of our agents do use multiple tabs to be able to keep their dashboard front and centre so I may look into that one (thanks Phaneendra).

------------------------------
Kieran Exley
Senior Unified Communications Services Specialist
------------------------------

Most areas are pretty much covered here relating to connectivity or device. One area that does crop up is headset controls. Other applications, particularly MS Teams and Webex can take control of Audio devices and not cleanly disconnect them.

I've noticed this more than the average user as I'm often demonstrating something and need to be aware of which audio is being used for which app. However this can occur with users that have internal tools and then come off a meeting and then go on queue and the device is not available.

------------------------------
Richard Chandler
Connect
------------------------------

In my experience it is almost always network related. On rare occasions I've seen things like the browser tab sleeping (or user having both the desktop app and browser version open), causing an issue.

But mostly I think it's a network problem that is never simple to resolve.

------------------------------
James Dunn
Telecoms Specialist
------------------------------

Hi,

If a user misses an offered interaction, this "error" is expected when the next interaction is offered to the same user. In cases where a user did not miss an offered interaction, browser logs or console logs is a requirement. Using the remote capture logs that Genesys Cloud have does not capture the needed network entries when the error occurs. 

From previous incidents, one or a combination of these  components causes the error:

• Network
• 3rd Security Software
• Windows Firewall
• VPN Client

Running the  Genesys Cloud WebRTC Standalone Diagnostic Tool also validates most of the network root causes. 

HTH 

------------------------------
Robernard
PROBE GROUP AUSTRALIA PTY LTD
------------------------------

Network is certainly a major factor and network security appliances like ZScaler certainly complicate things, but we have also found a few other conditions that cause this to happen.

1. If you don't have "Count non-ACD calls in utilization capacity" checked in your utilization settings, it is very easy for an agent to leave themselves on queue and place a personal outbound call.  When an ACD call is sent to them, they will be placed in not responding.
2. If a customer abandons right when they go into queue we have seen it put an agent into not responding.  Effectively, Genesys tries to route the call to an agent, but the customer abandons too quickly.  This shows as the call landing and alerting at the agent for just a second or two and then hangs up.  Because the agent did not answer the call, the agent goes into not responding.  We have our agents set for auto-answer and it affect them too.  The alerting is just not long enough for the Genesys client to answer the call.
3. If an agent closes their Genesys client without explicitly logging out of Genesys (as in the end of the day) and ANY call tries to route to them, then the agent will end up in not responding.  I think that Genesys has addressed this for the most part, but it can still happen within about a 10 second period immediately after they close their browser.  What is interesting about this is that the agent didn't even have to be on queue when they closed their client - the call could have been a personal call to their extension and it would have the same effect.

------------------------------
Patrick Jones
NA
------------------------------

Great discussion! One thing I would add is the importance of correlating the client-side evidence with the conversation details in Genesys Cloud.

When investigating Not Responding cases, I usually find it useful to start with the Conversation ID and exact timestamp, then check the conversation details to understand what actually happened during the alerting segment - how long the interaction was alerting, which agent/station was involved, and whether there were multiple routing attempts.

This can help separate an actual WebRTC/client issue from cases where the interaction was only offered for a very short time, was abandoned by the customer, or was affected by another routing condition.

For intermittent issues, having a simple process for agents to immediately capture the Conversation ID, timestamp, and what they saw on screen can also make a big difference. Without that information, troubleshooting later becomes much harder because everything may already be working normally again.

Really interesting to see how many different causes can lead to the same Not Responding symptom.

------------------------------
Weslley Bezerra
-
------------------------------

Our org is tracking 8 or now possibly 9 different instances of Not Responding/Alert No Answer issues that are NOT agents simply missing interactions; we are using the Salesforce Omni-Channel/CX cloud integration. The most frequent instances our agents report are 1) not having any clue whatsoever that they missed any interactions and only finding out when their supervisors alert them (so they receive NO audible or visual alert in Omni-Channel, and don't even get the "Not Responding" prompt), 2) suddenly seeing the "Not Responding" prompt but no audible/visual alerts in OC, and 3) attempting to answer and sometimes even thinking the interaction has been successfully accepted because a case gets created in Salesforce, but suddenly they are Not Responding (in these cases, the impact is two-fold because the the case is stuck with the first agent even though the call rolls over to the next available agent... who then has to create a manual case). These and more have been ongoing for a few years for us now, even back to when we first started with the embedded framework before moving to Omni-Channel/Salesforce native integration. We have sent numerous logs and recordings and have had joint conversations with Genesys and Salesforce, but have no real resolution at this point. Even agents who follow our best practices guidelines to the letter (using a LAN/ethernet network connection whenever possible, restarting their machines every day before their shifts start, using only "approved" USB headsets, etc.) have chronic Not Responding/ANA issues. 

------------------------------
Stephanie Drinkard Molon
Project Manager - Application Training
------------------------------

Sometimes it's quite frustrating, we use Genesys Cloud WebRTC Standalone Diagnostic Tool, it mark all OK/Pass but the issue is present trying to locate the cause we got against a wall in meeting with providers, technicians, users, etc.

Let's ask to the communit, beside Genesys Cloud WebRTC Standalone Diagnostic Tool, take logs, network capture, what tools do you use? What approach you take to solve this kind of issues?

Regards,

SG

------------------------------
Saugort Dario Garcia
Arquitecto de soluciones
e-Contact
https://www.e-contact.cl/
------------------------------

Hi Keshav, 

Great topic! I've encountered this issue in multiple Genesys Cloud environments, and in my experience the challenge is less about troubleshooting the symptoms and more about capturing evidence before the issue disappears.

Most common root causes I've seen:

• Network instability (brief packet loss, latency spikes, or Wi-Fi roaming between access points)
• VPN/proxy inspection affecting WebRTC media traffic
• Resource contention on the agent workstation (high CPU during screen recording, multiple browser tabs, Teams meetings, etc.)
• VDI environments where audio device redirection or network optimization is not properly configured
• Browser updates or extensions introducing intermittent conflicts

Logs and diagnostics I collect first:

1. Genesys Cloud browser console logs
2. HAR/network trace during the incident
3. WebRTC internals 
4. Genesys Cloud troubleshooting logs
5. Endpoint metrics (CPU, Memory, Network)
6. User impact details:
   • One-way audio or no audio?
   • Single user or multiple users?
   • Single site or multiple locations?
   • Internal calls only or external calls as well?

Best practices that have helped reduce incidents:

• Use a supported browser version and keep it updated.
• Prefer wired connections over Wi-Fi for contact center agents.
• Exclude Genesys Cloud traffic from SSL inspection where permitted by security policy.
• Establish baseline network monitoring for latency, jitter, and packet loss.
• Create a "capture-at-incident" procedure so supervisors or agents can immediately gather logs when the issue occurs.
• Regularly review VDI optimization settings if using Citrix or VMware environments.

One lesson I've learned is that when the issue is truly intermittent, identifying a pattern (same location, same ISP, same queue, same time of day, same browser version, etc.) often provides more value than analyzing a single occurrence. Correlating the incident with network performance metrics has helped uncover root causes more often than application logs alone.

Curious if others have seen network quality metrics (jitter/packet loss) being the primary factor, or if browser-related issues are more common in your environments.

Thanks,

------------------------------
Francis Guo
NA
------------------------------

------------------------------
Rolvin Voltaire Tuvida
Technology Specialist - Genesys Cloud
------------------------------

Hi @Keshav Manhas,

This type of issue, unfortunately, does not have a single root cause and can be caused by several factors. In most of the cases I have worked on, excluding connectivity-related issues, the main causes are related to browser configuration and workstation performance.

Here in Brazil, it is not uncommon to find contact centers using equipment whose performance is very close to the minimum requirements recommended by Genesys. When combined with various internal policies, antivirus software, and other systems running simultaneously, the result can be quite problematic.

Even with auto-answer enabled, the agent may be unable to accept the interaction because, at the moment it is received, the workstation may not be able to properly process all the required actions.

Before moving on to log collection or anything more complex and time-consuming, I usually check some of these points first: whether the workstation meets the minimum requirements, whether the browser is up to date, whether memory saver is disabled, whether there are any power-saving settings interfering with the application, and whether the necessary permissions are properly configured, such as pop-ups, microphone, among others.

------------------------------
Jhonatan Engel
Support Analyst
------------------------------