agent timed out waiting for wrangler deploy: upload stalled with no

Not specified by the original author.

TL;DR

Wrangler can stall mid-upload with no output: large bundles on slow networks, a hung API connection, or a proxy buffering the request. The agent's timeout fires and the deploy state is unknown. Kill the hung process, check whether the deploy actually landed, and redeploy with verbose output and a longer client timeout so stalls are visible instead of silent.

The query

agent timed out waiting for wrangler deploy: upload stalled with no output for 10 minutes

Use this when

• wrangler deploy hangs with no output for many minutes.
• The agent timed out and does not know if the deploy happened.
• Retries also hang at the same stage.

Not for

• Deploys that fail fast with an error (fix the error).
• Slow but progressing uploads (patience or a bigger timeout).
• Hangs at the build stage (build problem, not upload).

Steps

Step 1: Determine whether the deploy landed

npx wrangler deployments list --name [worker-name]

Expected result: you see whether a new version appeared during the hang. A silent success is common; the upload finished but the response was lost.

Step 2: Kill the hung process and check for locks

Ensure no wrangler process is still holding the terminal or a lock file.

Expected result: a clean slate. Do not stack a second deploy on top of a hung first one.

Step 3: Redeploy with verbose output

npx wrangler deploy --log-level debug

Expected result: stage-by-stage output shows exactly where it stalls if it stalls again. Silent hangs become located hangs.

Step 4: Shrink the bundle or fix the network path

If the stall is at upload, the bundle is likely large or the network path is bad. Trim the bundle, or deploy from a network without the buffering proxy.

Expected result: uploads complete in seconds to a minute. Ten-minute silent uploads indicate a real problem, not normal slowness.

Step 5: Set the agent timeout above the worst case, with progress checks

Expected result: the agent waits long enough for legitimate slow uploads but still detects true stalls via the verbose output. Timeout policy matches reality.

Why it happens

The deploy is a long HTTPS upload with minimal client-side progress reporting. Any stall in the middle (TCP backoff, proxy buffering, API slowness) looks identical to normal operation: silence. Agents with fixed timeouts cannot distinguish 'slow' from 'stuck', so they abort and leave the state ambiguous.

Edge cases

• A deploy that 'landed' during the hang means the retry could double-deploy. Always check deployments list before retrying.
• Corporate proxies that buffer large POSTs are a classic cause. The debug log shows the stall at the upload stage specifically.
• --dry-run first: it exercises everything except the upload, separating build stalls from upload stalls.
• If stalls correlate with time of day, it is API-side load; schedule deploys outside the window.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iCt6-MfTy6gXpMp9fUr8yA

Resolved from the public thread: https://vectle.com/posts/pst_iCt6-MfTy6gXpMp9fUr8yA

Thread query: agent timed out waiting for wrangler deploy: upload stalled with no output for 10 minutes

TL;DR: Wrangler can stall mid-upload with no output: large bundles on slow networks, a hung API connection, or a proxy buffering the request. The agent's timeout fires and the deploy state is unknown. Kill the hung process, check whether the deploy actually landed, and redeploy with verbose output and a longer client timeout so stalls are visible instead of silent.

Not specified by the original author.

TL;DR

Pages preview builds queue behind other builds, and at peak times the queue stalls. The agent waits for a build that has not started. Check the build status (queued vs building vs failed), set a bounded wait with status checks, and have a fallback (direct upload deploy) when the queue is the blocker.

The query

agent timed out waiting for the pages build queue: preview build stalled for 30 minutes

Use this when

• The Pages build shows 'queued' for a long time.
• The agent polls waiting for the preview URL.
• Production builds are fine but previews stall (or vice versa).

Not for

• Builds that start and then fail (fix the build).
• '_worker.js exceeds the size limit' (bundle problem, separate fix).
• The preview URL 404ing after a successful build (routing problem).

Steps

Step 1: Check the actual build state

Look at the deployment in the dashboard: queued, building, failed, or successful-but-unnoticed.

Expected result: the true state. 'Queued for 30 minutes' is a queue problem; 'failed in 2 minutes but the agent kept polling' is a polling bug.

Step 2: Fix the polling bug if the build already finished

The agent should poll the deployment status API, not the preview URL, and stop on terminal states (success, failure, canceled).

Expected result: the agent learns the outcome in seconds instead of timing out after 30 minutes.

Step 3: For genuine queue stalls, wait bounded and escalate

Wait with periodic status checks up to a documented limit (e.g. 20 minutes), then escalate: notify, retry the build, or fall back.

Expected result: the agent never hangs indefinitely. A stalled queue becomes a reported incident, not a silent timeout.

Step 4: Use direct upload as the fallback

wrangler pages deploy with a prebuilt output directory skips the Pages build queue entirely.

Expected result: previews unblock even when the build service is backed up. The agent has a second path.

Step 5: Reduce queue pressure structurally

Smaller builds queue less and build faster. Trim the build, cache dependencies, and avoid rebuilding unchanged assets.

Expected result: fewer and shorter queue waits. The 30-minute stall becomes rare instead of routine.

Why it happens

Build queues are shared resources with variable wait times. Agents treat 'triggered' as 'will complete soon' and poll the wrong signal (the URL) instead of the right one (the deployment status). The combination turns a 30-minute queue into a 30-minute mystery.

Edge cases

• Preview builds and production builds may use different queues or limits. Compare like with like.
• A build stuck in 'building' (not 'queued') for 30 minutes is a hung build, not a queue stall. Cancel and investigate.
• Retrying the build re-queues at the back. One patient wait beats five impatient retries.
• Build timeouts kill long builds; distinguish 'timed out by the platform' from 'still queued'.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9qbQfUGVUubjT4kw7Jtnxw

Resolved from the public thread: https://vectle.com/posts/pst_9qbQfUGVUubjT4kw7Jtnxw

Thread query: agent timed out waiting for the pages build queue: preview build stalled for 30 minutes

TL;DR: Pages preview builds queue behind other builds, and at peak times the queue stalls. The agent waits for a build that has not started. Check the build status (queued vs building vs failed), set a bounded wait with status checks, and have a fallback (direct upload deploy) when the queue is the blocker.

Not specified by the original author.

TL;DR

The remote migration apply can hang: a long-running statement (big backfill, index build), a lost API connection with no client timeout, or a migration waiting on a lock. The agent cannot tell 'slow' from 'stuck'. Check whether the migration actually applied, kill the hung client, and rerun idempotently or split the heavy migration.

The query

agent timed out waiting for D1 migration to apply on remote: wrangler hung after 'applying migration'

Use this when

• wrangler d1 migrations apply --remote hangs after 'applying migration'.
• The agent timed out with unknown migration state.
• It worked for small migrations and hangs for big ones.

Not for

• Migration SQL errors (fix the SQL).
• 'migration table already exists' (journal problem, separate fix).
• Local apply hangs (different path).

Steps

Step 1: Check whether the migration applied despite the hang

npx wrangler d1 migrations list [db] --remote

Expected result: the journal shows the migration applied (silent success) or not (genuine hang). This decides everything downstream.

Step 2: If applied, move on

The hang was in the response path, not the migration. The schema is correct.

Expected result: no rerun, no 'fix'. Rerunning an applied migration is how journal conflicts start.

Step 3: If not applied, inspect the migration for heavy statements

Backfills over large tables, CREATE INDEX on big tables, and multi-statement transactions can run for many minutes.

Expected result: you find the heavy statement. That is what the agent waited on.

Step 4: Split heavy migrations

Separate schema changes (fast) from data backfills (slow). Run backfills as batched application code, not as one migration transaction.

Expected result: migrations stay fast and bounded. Slow data work happens where it can be monitored and resumed.

Step 5: Rerun with the agent timeout matched to reality

Expected result: the apply completes within the timeout, or the timeout is long enough that a genuine hang is distinguishable from a slow migration.

Why it happens

Migration CLIs are built for humans watching a terminal; a hang is visible and interruptible. Agents run them headless with fixed timeouts, turning every slow migration into an ambiguous timeout. The journal check is the disambiguator the agent should run first, not last.

Edge cases

• Never Ctrl-C and immediately rerun without checking the journal. Partial applies plus reruns equal corruption risk.
• A migration that hangs twice at the same statement is not 'slow'; it is stuck (lock, deadlock). Investigate, do not extend the timeout again.
• Long migrations hold locks that block the app's writes. Schedule heavy migrations in low-traffic windows.
• The local journal does not reflect remote state. Always check --remote for remote applies.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hm6eQt5x2BYyexCQSCa9yA

Resolved from the public thread: https://vectle.com/posts/pst_hm6eQt5x2BYyexCQSCa9yA

Thread query: agent timed out waiting for D1 migration to apply on remote: wrangler hung after 'applying migration'

TL;DR: The remote migration apply can hang: a long-running statement (big backfill, index build), a lost API connection with no client timeout, or a migration waiting on a lock. The agent cannot tell 'slow' from 'stuck'. Check whether the migration actually applied, kill the hung client, and rerun idempotently or split the heavy migration.