LiveKit Cloud Agent Running but receives neither automatic nor explicit dispatch jobs

Agents
1

Paste this into the body:

I have a LiveKit Cloud Agent that reports healthy/Running, but dispatched jobs never reach the worker. I can reproduce the problem entirely with the LiveKit CLI, independent of my iOS application.

Environment

Project: you-meet-recovery
Agent ID: CA_smUaRATRtoCW
Agent deployment: you-meet-transcriber
Worker version: mFJXzH6NC8Cq
Region: us-east
Deployment: production
Status: Running
Replicas: 1 / 1 / 1
Agents JS: @livekit/agents 1.9.1

CLI reproduction

I created the room:

you-onboarding-synthetic-default

I then joined it from the LiveKit CLI as:

synthetic-default

The CLI reports a successful connection and the participant remains ACTIVE.

I tested automatic dispatch. LiveKit created:

AD_NbMWnKVkacGi

I also tested an explicit production dispatch to you-meet-transcriber. LiveKit created:

AD_xzTTr2mqoqxm

lk dispatch list shows both dispatch records for the room, and lk dispatch get successfully retrieves them.

However, no agent participant ever joins the room with either dispatch method.

The Cloud Agent continues to report Running with a healthy replica, but the agent entrypoint is never invoked and the Cloud Agent logs show no incoming job request, rejection, assignment error, or entrypoint execution.

Things already tested

  • Current ServerOptions instead of deprecated WorkerOptions
  • @livekit/agents 1.9.1
  • Default LiveKit job-acceptance lifecycle
  • numIdleProcesses: 0
  • Clean worker redeployments/restarts
  • Explicit dispatch with agentName: you-meet-transcriber
  • Explicit production deployment
  • Unnamed automatic dispatch
  • A completely synthetic CLI-created room and CLI participant, eliminating the mobile application from the reproduction

The key issue appears to be.

LiveKit accepts and persists the dispatch, but the Running Cloud Agent never receives/executes the job.

Could someone from LiveKit please inspect the backend assignment state for these dispatches?

Automatic: AD_NbMWnKVkacGi
Explicit: AD_xzTTr2mqoqxm

In particular, I’d like to know whether there is a worker-registration, agent-name/deployment-routing, or assignment-service issue associated with CA_smUaRATRtoCW.

I’m happy to provide any additional logs or IDs needed.

2

I believe your agent is crashing, do you see anything in your agent logs:

Also, for automatic dispatch the agent must not have a name, but yours does.

3

Thanks Darryn. I tested this again using the CLI so the mobile application is completely out of the reproduction.

The agent does not appear to be crashing. It appears that the dispatch is not waking the Cloud Agent at all.

Agent ID: CA_smUaRATRtoCW
Agent name: you-meet-transcriber
Deployment: production
Version: mFJXzH6NC8Cq

I created a fresh room:

you-agent-log-repro

Then created a fresh explicit production dispatch:

AD_pxLpYrkVkLEP

LiveKit successfully created the dispatch and lk dispatch get retrieves it.

Immediately afterward I ran:

lk agent logs --id CA_smUaRATRtoCW

LiveKit returned:

“The agent has shut down due to inactivity. It will automatically start again when a new session begins.”

I then ran lk agent status. The agent remains:

Status: Sleeping
Replicas: 0 / 1 / 1

So the explicit dispatch is being created and persisted, but it does not wake the sleeping Cloud Agent, which means there are no runtime logs/job logs to inspect.

Regarding automatic dispatch: agreed—the existing Cloud deployment is named, so let’s disregard our automatic-dispatch test. The explicit named production dispatch above should still wake you-meet-transcriber, but it doesn’t.

Can you check the backend assignment/wakeup state for AD_pxLpYrkVkLEP and CA_smUaRATRtoCW?

4

Ah, it looks like you have exceeded your free tier limit for session minutes, that will cause the agent to not be dispatched.

It should work as follows:

Start agent logs in one terminal window:

lk agent logs

In a second terminal window, create the room:

lk room create --name test-room

Then in that same terminal, dispatch the agent:

lk dispatch create --agent-name your-agent-log-repro --room test-room

You should see some activity in the first terminal window, for the agent, for example I see:

{"message": "process initialized", "level": "INFO", "name": "livekit.agents", "pid": 522, "elapsed_time": 0.05, "region": "us-east", "timestamp": "2026-10-06T09:01:19.259694+00:00"}

Back in the second terminal window, run lk room list and you should see one participant:

┌─────────────────┬────────────┬──────────────┬────────────┐
│ RoomID          │ Name       │ Participants │ Publishers │
├─────────────────┼────────────┼──────────────┼────────────┤
│ RM_azjkUEALsNQH │ test-room  │ 1            │ 0          │
└─────────────────┴────────────┴──────────────┴────────────┘

If you don’t see 1 participant, something went wrong with the dispatch

The dashboard doesn’t update immediately, but after a minute or so you should see the ‘Session events’ tab update to say the agent has joined.

Try that when the limits reset. If that still doesn’t work, it could be your agent code so create a new agent from the starter app and try with that.