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.

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