Eval runs stuck queued (dashboard + API), 0 turns,...
# support
m
Severity: High — all eval runs dead org-wide, blocking pre-deploy regression testing. Org ID: b0f738d5 · Account: egleyboise@gmail.com · First seen 2026-06-07, still reproducing 2026-06-08. Every Eval Run is created but never executes any turns — on BOTH the dashboard and the API: - Dashboard: run shows "Running" forever, Duration <1s, Total/Eval Turns = 0. After refresh the assistant label decays to "Unknown Assistant." - API: POST /eval/run is accepted, then GET /eval/run/{id} stays status:"queued" forever — never → running/ended; endedReason/endedMessage stay null. 100% reproduction, multiple days, every assistant. No credits consumed. Looks like the eval execution/worker layer is down for our org (queue accepts, nothing is picked up) — not a UI or config issue. Example stuck API run: 5b63803c-2f39-436a-a04d-660b43e06c72 Eval: 22425619-54ee-4bdd-a232-5cd451b82fe2 ([ETA-EVAL] ALL-01-a5) Assistant: c9880898-3c0c-4ca8-8386-f86d29e92edc Repro (dashboard): Test → Evals → pick any eval → Run → select assistant → confirm → run sits "Running" forever, 0 turns. Questions: 1) Known org-scoped issue where eval runs never leave queued/running for org b0f738d5? 2) Why does the assistant decay to "Unknown Assistant"? 3) Both dashboard + API hit the same stuck engine — what's the path to restore a working eval layer? 4) Can you share internal run-level error logs for run 5b63803c (endedReason/endedMessage are null)? Need a working eval path (or an incident ETA) to run our 16-case regression suite before shipping prompt changes. Happy to provide more run IDs. (Minor: a default user-agent got Cloudflare error 1010 from api.vapi.ai; a browser UA was needed to reach the API. Flagging in case it's edge-related.)
I switched the org channel from daily to weekly as suggested and re-tested. Eval runs are STILL stuck in "queued" indefinitely on the weekly channel — identical to before. New run on the weekly channel: - Run ID: 6977ef7f-cd7c-4741-8c30-b6c49bb5a693 - Eval: 22425619-54ee-4bdd-a232-5cd451b82fe2 ([ETA-EVAL] ALL-01-a5) - Assistant: c9880898-3c0c-4ca8-8386-f86d29e92edc - GET /eval/run/{id} returns status:"queued", endedReason/endedMessage null, for 2+ minutes and counting. So both the daily and weekly channels reproduce this for org b0f738d5 — it looks org-scoped at the eval worker/queue layer, not channel-dependent. That run (6977ef7f...) is sitting queued right now. Screen recording attached: https://www.loom.com/share/221ae2d2efcb4968a44c45883d20af0b
j
This sounds like a backend queue/worker issue rather than an eval configuration problem. Since runs are being created successfully but never leave "queued" across both the dashboard and API, and on both daily and weekly channels, the execution layer doesn't appear to be picking up jobs for your org. The "Unknown Assistant" behavior is especially concerning because it suggests metadata may be failing to resolve after run creation. Have you been able to confirm whether other orgs are successfully processing evals during the same period, or if support can check worker logs for run IDs 5b63803c-2f39-436a-a04d-660b43e06c72 and 6977ef7f-cd7c-4741-8c30-b6c49bb5a693? Given that this is blocking your entire regression suite, an internal investigation into the eval queue and worker assignment for org b0f738d5 seems warranted. @Michael Egley
m
32h update: still 100% reproducing for org b0f738d5 on both channels. Can a Vapi engineer pull the eval worker/queue logs for runs 5b63803c and 6977ef7f and confirm incident status + ETA? This is the only thing left that unblocks us. 🙏
j
32+ hours with runs never leaving the queue definitely points to something deeper than an eval configuration issue. At this stage, I'd be looking closely at the org-level worker assignment, queue processing, and internal execution logs tied to those run IDs. If you'd like another set of eyes on it, feel free to reach out privately. I've worked through similar Vapi debugging cases and may be able to help identify a path forward while you're waiting on engineering. @Michael Egley