Evaluating Genesys Cloud web messaging for a client and we have hit a dealbreaker UX issue. The web messaging conversation is automatically closing after exactly 10 minutes of “inactivity,” but the definition of inactivity is broken.
Scenario: Customer opens a web messaging chat, sends a message, gets connected to an agent. The agent asks for the customer’s order number. The customer starts searching through their email for the order number - this takes about 12 minutes. During this time, the customer is on the page with the messenger widget open and visible. They have not navigated away.
After 10 minutes, the conversation auto-closes with a system message: “This conversation has been ended due to inactivity.” The customer then types their order number and it creates an entirely new conversation with a different agent. Complete context loss.
The customer did not leave the page. The browser tab was active. The widget was open. The only thing that did not happen was a message being sent in the chat window.
Is there any way to extend this timeout or change the inactivity definition to include page focus or typing indicators rather than just sent messages?
The 10-minute idle timeout is configurable but not where most people look for it. It is not in the queue settings or the Architect flow - it is in the Messenger Deployment configuration.
Go to Admin > Message > Messenger Deployments > [Your Deployment] > Conversation Settings. There is a field called “Idle Timeout” with a default of 600 seconds (10 minutes). You can increase this up to 86400 seconds (24 hours).
But here is the thing - even if you increase the timeout, the platform only considers sent messages as “activity.” Typing indicators, page focus, and scroll events do not reset the timer. This is by design because the timeout is evaluated server-side, and the server only knows about actual message events.
The workaround we use for our gamification engagement flows is to inject a keep-alive message from the Architect flow. Set up a “Wait” action in your inbound message flow with a 8-minute timeout. When the wait expires without a customer message, have the flow send an automated message like “Are you still there? Take your time - I am still here to help.” This resets the idle timer and also doubles as a good customer experience nudge.
The deployment-level idle timeout configuration is the correct answer. During our CXone-to-GC migration, we set this to 3600 seconds (1 hour) for our insurance claims queue because customers frequently need to locate policy documents mid-conversation.
There is an additional consideration for the JavaScript SDK approach. If you want true client-side activity detection (typing, scrolling, mouse movement) to prevent disconnection, you can implement a custom keep-alive using the Messenger SDK:
let inactivityTimer;
function resetKeepAlive() {
clearTimeout(inactivityTimer);
inactivityTimer = setTimeout(() => {
Genesys('command', 'Messenger.sendMessage', {
message: '[Customer is still active on page]'
});
}, 480000); // 8 minutes
}
window.addEventListener('mousemove', resetKeepAlive);
window.addEventListener('keypress', resetKeepAlive);
window.addEventListener('scroll', resetKeepAlive);
This sends a keep-alive message to the conversation only if the customer has been interacting with the page. The agent will see the bracketed message, which indicates the customer is still present but has not typed a chat message. You can then filter these keep-alive messages from QM evaluations by checking for the bracket pattern in the transcript.