## 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

```text
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

```bash
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

```bash
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