Hi LiveKit team đź‘‹

Getting Started
,
1

Hi LiveKit team :waving_hand:

We run production telephony voice agents on LiveKit Cloud (eu-central), livekit-agents 1.6.4, SIP inbound via Twilio trunk, STT = Deepgram plugin (nova-3, base_url=``api.eu.deepgram.com, fr).

Symptom: on a share of real calls, Deepgram stops emitting everything (no finals, no interims) for 60-90s mid-call, then resumes on the same WebSocket — no error, no WS close, keepalives accepted throughout. The caller keeps speaking the whole time (local VAD confirms it), and everything said during the gap is lost — our “I can’t hear you” re-prompt loops and patients end up repeating themselves 3 times or calling back.

Documented example (2026-07-30, UTC): connection established 15:13:32 → last Deepgram message 15:14:01 → silent 15:14:01→15:15:15 (74s) → resumes on its own → normal close 15:15:57. Deepgram request ID 019fb396-7f5a-7770-b6f1-39bf6e7bfe62 — and Deepgram’s console shows 2:16 of audio received/billed for a 2:25 call, so audio reached them during the gap. Two more affected requests same day: 019fb399-8927-7a20-88b1-e8ba91440c79 (15:16:51) and 019fb3a8-c369-7f82-97b5-664bb786c8c6 (15:33:29).

Ruled out on our side: VAD (speech detected throughout the gaps), session endpointing (raised to 0.5/2.0), keepalive format, LLM (not invoked during gaps). We now log per-10s counters on every call (frames pushed / ws.send_bytes / DG messages received) plus DEBUG plugin logs — happy to share extracts.

This looks like the same family as this SIP dead-zone thread and this one where temporary unreported Deepgram downtime was suspected.

Two asks:

  1. Since the agent workers run on LiveKit Cloud, could someone check host/egress metrics for our agent’s workers during those windows (agent CA_FtBUwaXiLxge, eu-central)? We want to distinguish an egress/network stall from a Deepgram-side one.
  2. Has anyone else seen this on telephony recently? Any known mitigation besides detect-and-reconnect?

Deepgram support ticket is open in parallel with the same request IDs. Happy to provide room names / session IDs.

Thanks!

2

Since the agent workers run on LiveKit Cloud, could someone check host/egress metrics for our agent’s workers during those windows (agent CA_FtBUwaXiLxge, eu-central)? We want to distinguish an egress/network stall from a Deepgram-side one.

This is for call RM_baYKZmZVGNF3 ?

Looking at the load on the agent worker that served this session, the machine was not stressed at all.

I also don’t see anything in the server logs that could explain this. Honestly, to me it looks like a Deepgram issue, and I recommend following up with their support, but I wanted to rule out any issues on our side. As I’m sure you’ve already checked, I’m surprised there is nothing on https://status.deepgram.com/ .

3

Thanks for checking, and yes, RM_baYKZmZVGNF3 is the right call (started July 30, 15:13:31 UTC; the STT went silent from 15:14:01 to 15:15:15 UTC, a 74-second gap while the caller was speaking). Two other calls were affected the same day, if you want to cross-check: one starting 15:16:51 UTC and one at 15:33:29 UTC (same agent).

Your findings actually fit perfectly with what Deepgram support just told us. Deepgram has identified a network degradation between GCP and Deepgram, starting in late July, affecting applications running on GCP (WebSocket handshakes taking 7–30s+, not reproducible from other clouds). Since LiveKit Cloud agents run on GCP, our workers are affected. That’s consistent with what you saw: host not stressed, nothing in server logs , the issue is in the network path to Deepgram, not on your machines. It also explains why status.deepgram.com shows nothing: it only affects GCP-originated traffic, not the Deepgram platform itself.

The Deepgram ticket is TKT-23601 (contact: Trevor Sullivan). He told us Deepgram has already engaged the LiveKit team and GCP support on this. Could you connect with them internally referencing that ticket, so both sides are working from the same diagnosis? We keep seeing 60–90s silent STT gaps on real calls in the meantime (agent CA_FtBUwaXiLxge, eu-central).

Thanks!

4

OK, thanks, let me look into this and make sure everyone has all the required information.