agent's scheduled deploy failed silently: cron trigger fired while agent was mid-edit

TL;DR: Stop deploying on a bare schedule. Gate every deploy behind a "no edits in progress" check - a lock file, a clean git worktree, or a deploy-in-progress flag - and verify the deploy actually landed by listing deployments afterward. The failure is silent because nothing watches the deploy after the trigger fires: the cron event runs, the bundle is half-written, and nobody reads the result.

agent's scheduled deploy failed silently: cron trigger fired while agent was mid-edit

1. Check whether the broken deploy is the live one: run npx wrangler deployments list. Expected: a list with the latest deployment marked active; compare its timestamp to when you started editing.

2. Roll back to the last known-good version if the bad deploy is live: run npx wrangler rollback. Expected: output confirming the previous version is active again.

3. Add a deploy gate before every scheduled deploy: check for an in-progress marker (a lock file in the repo, or uncommitted changes via git status --porcelain). Expected: git status --porcelain prints nothing, meaning the tree is clean.

4. Make the scheduled trigger check the gate first and skip the deploy when edits are in flight. Expected: the run logs "deploy skipped: work in progress" instead of publishing a half-written bundle.

5. Verify the deploy after every trigger: poll npx wrangler deployments list until the new version shows active. Expected: the new deployment appears as active within a few minutes.

Use this when

• a cron trigger or scheduled job deploys the worker instead of a human or CI pipeline step
• a deploy went out while files were still being edited and broke production
• the deploy "succeeded" according to the trigger but the worker serves the wrong version
• an agent edits and deploys in the same loop with no coordination between the two

Not for this skill when

• the deploy failed loudly with a build error - that is a build failure, not a silent race
• the issue is a wrangler auth or account error on deploy
• you want to schedule the worker's own cron handler (a scheduled event), not deploys

Variant phrasings

• cron deploy went out mid-edit and broke the worker silently
• scheduled wrangler deploy raced the agent's edit loop
• worker deploy fired on schedule with uncommitted changes

Why it happens

A cron trigger fires on the clock, not on readiness. If the agent (or a human) is mid-edit when the trigger fires, wrangler bundles whatever is on disk at that second - half-written files, a broken import, an unfinished wrangler config change. wrangler deploy exits 0 even when the result is a broken worker, and a cron context never shows anyone the output. So the deploy is both premature and unobserved: the two conditions that make it silent.

Edge cases

• wrangler rollback only rolls back the worker code, not KV, D1, or R2 data changes the bad deploy may have made. Check storage state too.
• A skipped deploy leaves the schedule unchanged - the next trigger retries. Make sure skipped deploys are logged somewhere the agent reads, or the agent will assume the deploy happened.
• If edits take longer than the cron interval, every trigger skips and nothing ever deploys. Alert when skips pile up (three in a row is a good threshold).
• Rolling back does not fix a broken wrangler config change; verify wrangler.toml parses before re-deploying.

Provenance

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