https://livekit.io logo
Join Slack
Powered by
the deployed agetn is still on pending
# ask-ai
s
the deployed agetn is still on pending
✅ 1
t
Thanks for reaching out, Joshua. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m sorry the agent is stuck in Pending. I can help get this sorted. A few quick questions so I can pinpoint the cause: • Which command or UI did you use to deploy the agent (e.g., 
lk agent deploy
)? • What region/project and the agent name or ID? • Can you run 
lk agent status
(or tell me what it shows) and share the output? • Please run 
lk agent logs --tail
for that agent and paste any recent errors or messages (especially anything mentioning resource allocation, failing containers, or signal/drain issues). In the meantime, try these checks (they often resolve Pending states): • Verify there are enough resources on the node (CPU/memory) and no other apps starving the agent. • Confirm there are multiple replicas configured (insufficient replicas can block progress). • Check autoscaling settings to ensure scale-up is allowed. • Inspect startup wrapper scripts: if you use a custom wrapper, ensure it uses 
exec
so the agent receives SIGTERM/SIGINT (otherwise draining/drain completion can hang). • If you see long first-connect delays, note that cold starts can temporarily keep an instance pending while it initializes. Send the 
lk agent status
output and any relevant logs and I’ll propose the exact next steps. Sources: Deployment reliability on LiveKit Cloud | LiveKit, with interactive elements
s
┌─────────────────┬──────────────┬─────────┬────────────┬────────┬─────────┬───────────┬──────────────────────┐ │ ID │ Version │ Region │ Status │ CPU │ Mem │ Replicas │ Deployed At │ ├─────────────────┼──────────────┼─────────┼────────────┼────────┼─────────┼───────────┼──────────────────────┤ │ CA_fXUDAbLAFASg │ 8ZUWKSXDQvKP │ us-east │ Scheduling │ 0m / 2 │ 0 / 4GB │ 0 / 1 / 1 │ 2026-05-06T074636Z │ └─────────────────┴──────────────┴─────────┴────────────┴────────┴─────────┴───────────┴──────────────────────┘
t
Thanks — that status helps. I’m responding about the agent showing Status = Scheduling with 0/1 replicas and 0 CPU / 0GB memory allocated. Please run and paste the output of these two commands so I can see why scheduling is failing: 1. 
lk agent logs --tail CA_fXUDAbLAFASg
2. 
lk agent status --verbose CA_fXUDAbLAFASg
(or 
lk agent status --all
if verbose isn’t available) While you gather those, please confirm: • Is your project/region allowed to scale in us-east (any quota limits)? • Have there been any recent changes to resource requests/limits for this agent version? Quick checks you can try now: • Verify node capacity (CPU/memory) in the target region; Scheduling often means no node has the requested resources. • Ensure replicas are allowed to scale up (check autoscaling settings or replica limit). • If you use a custom startup wrapper, ensure it uses 
exec
so the agent process can receive SIGTERM/SIGINT. • If logs show image-pull or permission errors, share the log lines and I’ll interpret them. Send the two command outputs and answers to the confirmations and I’ll give the exact next steps. , with interactive elements
s
┌─────────────────┬──────────────┬─────────┬────────────┬────────┬─────────┬───────────┬──────────────────────┐ │ ID │ Version │ Region │ Status │ CPU │ Mem │ Replicas │ Deployed At │ ├─────────────────┼──────────────┼─────────┼────────────┼────────┼─────────┼───────────┼──────────────────────┤ │ CA_fXUDAbLAFASg │ 8ZUWKSXDQvKP │ us-east │ Scheduling │ 0m / 2 │ 0 / 4GB │ 0 / 1 / 1 │ 2026-05-06T074636Z │ └─────────────────┴──────────────┴─────────┴────────────┴────────┴─────────┴───────────┴──────────────────────┘
t
Thanks — I’m looking at the agent showing Status = Scheduling with 0/1 replicas and 0 CPU / 0GB allocated. That typically means the platform can’t place the pod because no node meets the requested resources or quotas/rate limits are preventing scaling. I can help diagnose — please run and paste the outputs of: 1. 
lk agent logs --tail CA_fXUDAbLAFASg
2. 
lk agent status --verbose CA_fXUDAbLAFASg
(or 
lk agent status --all
) Also confirm: • Do you have any regional quota limits in us-east that might block 2 CPU / 4GB allocation? • Were resource requests or replica settings changed for this version recently? • Are you using any custom startup wrapper scripts for the agent? Quick things you can check now: • Verify node capacity in us-east (available CPU/memory). • Ensure autoscaling/replica limits allow at least 1 replica. • Check logs for image-pull, permission, or scheduling error lines (share them if you see any). Send the two command outputs and answers to the confirmations and I’ll give exact next steps. , with interactive elements
s
Incorrect Usage: flag provided but not defined: -tail flag provided but not defined: -tail
t
Thanks — that error explains why logs didn’t show. I’m responding about getting the correct logs and next troubleshooting steps for the agent stuck in Scheduling. Please run these (no 
--tail
flag): 1. 
lk agent logs CA_fXUDAbLAFASg
— paste the recent log output. 2. 
lk agent status --verbose CA_fXUDAbLAFASg
(or 
lk agent status --all
) — paste the output. Also confirm: • Any regional quota limits in us-east (CPU/memory) or changes to quota recently? • Whether you changed resource requests/limits or replica settings for this version? • If you use a custom startup wrapper for the agent? Quick checks you can do now: • Verify node capacity in us-east (enough free CPU/memory to satisfy 2 CPU / 4GB). • Ensure autoscaling/replica limits allow at least 1 replica. • If logs show image-pull or permission errors, copy those lines here. Send the two command outputs and answers and I’ll identify the root cause and next steps. , with interactive elements
s
is this because of my subscription is free
t
Thanks — I’m responding about whether your free subscription could cause the agent to remain in Scheduling. Yes. The free (Build) plan has stricter quotas that can cause Scheduling/Pending when resources or limits are exceeded: • Only 1 agent deployment allowed and limited concurrent sessions (5). • Lower included agent session minutes and no cold-start prevention, so agents may scale to zero and experience scheduling delays. • Regional resource/quota limits can prevent placing a 2 CPU / 4 GB replica if capacity or your quota is exhausted. What to check next: • Open the LiveKit Cloud dashboard and confirm your plan, current agent deployments, session minutes used, and regional quotas. • Verify no other deployment is using the single allowed agent or consuming the CPU/memory quota in us-east. • Run 
lk agent logs CA_fXUDAbLAFASg
and 
lk agent status --verbose CA_fXUDAbLAFASg
and paste any error lines if you still see Scheduling after confirming quotas. If you need higher quotas (more replicas, higher CPU/memory, cold-start prevention), upgrading to a paid plan (Ship or Scale) will remove those limits. Tell me what you find in the dashboard or paste the verbose status/logs and I’ll help with the next steps. Sources: Deployment reliability on LiveKit Cloud | LiveKit | Deployment reliability on LiveKit Cloud | LiveKit | Pricing | LiveKit | https://livekit.com/pricing.md| | Pricing | LiveKit, with interactive elements
2 Views
Open in Slack
PreviousNext
Powered by