This is a tough one. While yes I do recommend still opening a support case as the Care team will have more access to backend logs and other tools. Just make it clear that this issue is not reproducible and no console and network logs where captured. I image they will need the affected users and user ids, as well as a time frame to even start looking. From the logging you provided, the agent went on queue in the backend
Original Message:
Sent: 02-19-2026 10:11
From: Jeremie SIMON
Subject: Routing Status "NOT_RESPONDING" without Presence Status "In queue"
Hello @Cameron Tomlin,
I used POST /api/v2/analytics/users/details/query to check Presence/Routing Status
When your Presence status is "Available, Break, Busy, Meal, etc..." (other than On Queue), you should have Routing Status "OFF_QUEUE"
When your Presence status is "On Queue", you can have these Routing Status "IDLE, INTERACTING, NOT_RESPONDING"
NOT_RESPONDING metric is intended to apply to the agent only when they don't answer before the end of the alerting timeout (as defined on the queue).
In these cases, I don't see any ACD interaction offered to agents, it's logical because you can receive interactions only when your Presence status is On Queue (with routing status IDLE).
So, the "NOT_RESPONDING" routing status should not be possible while the presence status is "Available," unless I'm mistaken?
I'd like to open a support case, but they'll probably request Console/Network logs I haven't been able to gather, given that I haven't reproduced the issue.
Do you think it's still worthwhile to try, even if I'm expecting that frustrating response? 🧐
Regards
------------------------------
Jeremie
IT
Original Message:
Sent: 02-19-2026 09:47
From: Cameron Tomlin
Subject: Routing Status "NOT_RESPONDING" without Presence Status "In queue"
Hello Jeremie,
Looking at the logs you provided it looks like both agents went on queue, not responding and then idle. If this wasnt the case then I would highly recommend opening a case with customer care. They will need to take a closer look at what is happening and dig into the logs more so than we can do here in a public forum.
Are there any interactions around both of these times the agents went not responding?
Cheers,
------------------------------
Cameron
Online Community Manager/Moderator
Original Message:
Sent: 02-19-2026 09:31
From: Jeremie SIMON
Subject: Routing Status "NOT_RESPONDING" without Presence Status "In queue"
Hello,
We recently activated these two parameters on our org :
- modern logic for processing WebRTC calls
- active persistent connection management
We've observed some rather strange behavior.
For example, a user logs into Genesys (so his presence changes to "Available" - 2026-02-17T08:19:44.357Z) and then his routing status switches to "Not Responding" (2026-02-17T08:19:47.825Z) even though they never received an ACD offer-which makes sense, since he never went "On Queue."
Here the logs :
"primaryPresence": [
{
"startTime": "2026-02-16T16:30:36.597Z",
"endTime": "2026-02-17T08:19:44.357Z",
"systemPresence": "OFFLINE",
"organizationPresenceId": "ccf3c10a-aa2c-4845-8e8d-f59fa48c58e5"
},
{
"startTime": "2026-02-17T08:19:44.357Z",
"endTime": "2026-02-17T08:32:36.477Z",
"systemPresence": "AVAILABLE",
"organizationPresenceId": "6a3af858-942f-489d-9700-5f9bcdcdae9b"
},
{
"startTime": "2026-02-17T08:32:36.477Z",
"endTime": "2026-02-17T08:52:16.090Z",
"systemPresence": "ON_QUEUE",
"organizationPresenceId": "e08eaf1b-ee47-4fa9-a231-1200e284798f"
},
"routingStatus": [
{
"startTime": "2026-02-16T16:27:36.964Z",
"endTime": "2026-02-17T08:19:47.825Z",
"routingStatus": "OFF_QUEUE"
},
{
"startTime": "2026-02-17T08:19:47.825Z",
"endTime": "2026-02-17T08:32:36.571Z",
"routingStatus": "NOT_RESPONDING"
},
{
"startTime": "2026-02-17T08:32:36.571Z",
"endTime": "2026-02-17T08:32:48.131Z",
"routingStatus": "IDLE"
},
How is possible to have routing status (other than OFF_QUEUE) with presence status "Available" ?
Same thing for another user :
"primaryPresence": [
{
"startTime": "2026-02-16T16:40:38.914Z",
"endTime": "2026-02-17T07:29:10.483Z",
"systemPresence": "OFFLINE",
"organizationPresenceId": "ccf3c10a-aa2c-4845-8e8d-f59fa48c58e5"
},
{
"startTime": "2026-02-17T07:29:10.483Z",
"endTime": "2026-02-17T07:30:33.768Z",
"systemPresence": "AVAILABLE",
"organizationPresenceId": "6a3af858-942f-489d-9700-5f9bcdcdae9b"
},
{
"startTime": "2026-02-17T07:30:33.768Z",
"endTime": "2026-02-17T08:49:45.226Z",
"systemPresence": "ON_QUEUE",
"organizationPresenceId": "e08eaf1b-ee47-4fa9-a231-1200e284798f"
},
"routingStatus": [
{
"startTime": "2026-02-16T16:40:07.273Z",
"endTime": "2026-02-17T07:29:15.492Z",
"routingStatus": "OFF_QUEUE"
},
{
"startTime": "2026-02-17T07:29:15.492Z",
"endTime": "2026-02-17T07:30:33.815Z",
"routingStatus": "NOT_RESPONDING"
},
{
"startTime": "2026-02-17T07:30:33.815Z",
"endTime": "2026-02-17T07:55:15.909Z",
"routingStatus": "IDLE"
},
I don't have console/network logs as always.
Too, we have observed a rise in prolonged "Idle" state without any calls being delivered, even as peers on the same queue have answered multiple interactions => switch on-queue > off-queue > on-queue appears to resolve the issue.
Additionally, some users lose audio after resuming from a manual hold.
Since enabling these two settings, I've found they cause more problems than deliver greater stability.
I'm also not sure whether this is related to a recent update.
I'm not expecting a precise diagnosis, because the issue is intermittent and collecting logs is that much more difficult.... what I'm mainly looking for is feedback based on your experience.
Perhaps this configuration has not been sufficiently tested, and it may be advisable to disable them for the moment ?
Regards
#Reporting/Analytics
#Routing(ACD/IVR)
#Telephony
------------------------------
Jeremie
IT
------------------------------