Your workspace's 10 concurrent deployment slots were saturated, most likely by the wave of 42 Postgres auto-updates that rolled through during the same window. Build/deploy concurrency is per workspace, so once all 10 slots were occupied, every other deployment across every project queued behind them. The backlog has now cleared: the deployments you cancelled freed the slots, and fresh deploys (including both the backend and worker services) are completing successfully with normal step timings as of ~19:12 UTC today.

The saturation has recurred and this time cancelling does not clear it. Since ~08:47 UTC today every deployment queues again ('Waiting for deployment slot'). We have since: removed ALL queued deployments in keppel-lp-service-dev (backend/worker/worker-llm/migration-ledger-watch) and in jason-health-backend (worker/api) via deploymentRemove; reduced replica limits (backend 5GB/worker 4GB/worker-llm 5GB, jason api+worker 2GB); freed ~7GB of reserved memory; then pushed a SINGLE fresh backend deploy (project dfa192d3-3b3c-41a6-8a01-ef92ddcb7b4d, env dev). It went INITIALIZING then BUILDING then back to QUEUED and has sat there 10+ minutes as the only queued deployment we can see. Compute usage $45.88 of $200. Can you check server-side what is occupying the 10 workspace slots and clear it? This has blocked production fixes for 6+ hours today.

To correct my earlier message, the slots are not free. All 10 of your workspace's deployment slots are held right now by 14 deployments of the migration-ledger-watch service, each stuck on its pre-deploy command since as early as 05:18 UTC today. These deployments show as BUILDING/DEPLOYING, not QUEUED, which is why removing queued deployments did not clear them. The pre-deploy command runs, outputs a migration manifest with "ok": false and 14 "unexplained_unrecorded" migrations, then never exits, so it holds its slot indefinitely. Cancel these specific migration-ledger-watch deployments via deploymentRemove (target the ones in BUILDING/DEPLOYING status, not QUEUED), and the backend deploy will start immediately. You will also want to fix the pre-deploy command so it exits non-zero on failure rather than hanging.