Session gets closed unexpectedly

[Vishal_Maurya]

Hi team,

I’m experiencing an issue where an interview session gets closed unexpectedly.

During a live interview, after around 7 minutes, the LiveKit connectionStatus suddenly changed and the interview session closed automatically. This is critical for us because interviews should never end midway while a candidate is still in the session.

Unfortunately, I’m unable to properly debug the issue because the Log Insights do not contain enough details about why the connection was closed.

Could you please help investigate what might have caused this?

Room ID: RM_AJVpYzRY9NJu

This issue is very important for our production workflow since it directly impacts candidate interviews. Any help identifying the reason (timeout, connection drop, server-side close, etc.) would be greatly appreciated.

Thanks!

[darryncampbell (Darryn)]

@Vishal_Maurya

RM_AJVpYzRY9NJu

For that particular session, the event log at Sign in | LiveKit Cloud shows CONNECTION_TIMEOUT as the reason the candidate was disconnected from the room.

If I look at the server logs for that time, I see a couple of messages that imply network connection issues with the client

[Vishal_Maurya]

Can you please share the error logs? That will help me understand what happened and suggest a fix to prevent it from occurring again.

I want know what happened, what’s the error and how to prevent

[CWilson]

You should check your agent logs for that info. We do not have your agent logs in our system.

Have a look at this guide Darryn recent plublishd on how to find agent logs:

Where to find your Agent Logs

[CWilson]

This appears to be a duplicate of

LLM failed and Logs are not reflected in Insight

Couple of possible reasons why you’re seeing this: You will only see agent logs emitted during the session, you won’t see any ‘dispatching’ agent logs by design, since agent observability logs only cover the period when the agent is in the room. By default, you only see INFO logs or higher for deployed agents, and DEBUG logs and higher when you run locally. More info: Where to find your Agent Logs | LiveKit

[son_huynh]

We also encountered the same error RM_ibjNcXcsKN38
The call restarted after about 2-3 minutes.

[darryncampbell (Darryn)]

@son_huynh

RM_ibjNcXcsKN38

@son_huynh I do see a CONNECTION_TIMEOUT for your agent - the first place to look for further clues would be your agent logs:

Where to find your Agent Logs

[son_huynh]

@darryncampbell

CONNECTION_TIMEOUT

This is the log we received when this issue occurred. It run on aws acs

2026-05-20T08:36:33.677Z	2026-05-20 08:36:33,677 - watchfiles.main - WARNING - received signal 15, raising KeyboardInterrupt
	2026-05-20T08:36:33.680Z	08:36:33.677 WARNING watchfiles.main received signal 15, raising
	2026-05-20T08:36:33.680Z	KeyboardInterrupt
	2026-05-20T08:36:33.680Z	2026-05-20 08:36:33,680 - livekit.agents - WARNING - exiting forcefully
	2026-05-20T08:36:33.681Z	08:36:33.680 WARNING livekit.agents exiting forcefully

2026-05-20T08:36:33.677Z	2026-05-20 08:36:33,677 - watchfiles.main - WARNING - received signal 15, raising KeyboardInterrupt
	2026-05-20T08:36:33.680Z	08:36:33.677 WARNING watchfiles.main received signal 15, raising
	2026-05-20T08:36:33.680Z	KeyboardInterrupt
	2026-05-20T08:36:33.680Z	2026-05-20 08:36:33,680 - livekit.agents - WARNING - exiting forcefully
	2026-05-20T08:36:33.681Z	08:36:33.680 WARNING livekit.agents exiting forcefully

[darryncampbell (Darryn)]

@son_huynh I’m not an expert in AWS hosting but I interpret those logs that something external to your self-hosted agent is instructing it to shut down, and then forcefully shutting it down.

I ran the error through Claude which confidently told me you were running the agents in dev mode rather than start, but I think that is unlikely

[Muhammad_Usman_Bashir]

@son_huynh, CONNECTION_TIMEOUT in the DisconnectReason enum is defined as the server-side timeout: “server timed out a participant session” livekit/protocol/protobufs/livekit_models.proto.

That puts the upstream cause on the client connection side (signaling/media stopped reaching the serverwithin the timeout window), so the agent logs in in the above link are where the client/agent timeline of the disconnect will be visible.