Which mechanism triggers automatic rollbacks for failed Cloudflare Worker deployments?

Direct answer

Cloudflare Workers does not provide a built-in, native trigger that automatically rolls back a Worker after a failed deployment or a runtime health-check failure. The only automatic safety behavior is atomic deployment: if a script upload fails validation, the previously active version keeps serving. A valid script that crashes at runtime is considered a successful deployment and will not be reverted by the platform.

Confirmed behavior vs. recommended pattern

Confirmed: Deployments are atomic. A failed upload does not replace the active version. Rollback is an explicit, manual operation available through the Cloudflare dashboard, the Workers API, and Wrangler.

Recommended pattern: Because no native health-check trigger exists, automated recovery must be built in your CI/CD pipeline. Record each deployment ID, run post-deploy verification, and invoke the documented rollback operation with the last known good ID when checks fail.

Implementing CI-driven recovery

1. Capture the baseline. Before promoting a new version, record the currently active deployment ID from the Workers deployment history.
2. Deploy and verify. Upload the new script. If the upload itself fails, the old version remains live—no action needed. If the upload succeeds, run smoke tests against the new version.
3. Rollback on failure. If post-deploy checks fail, call the rollback operation with the captured deployment ID to restore traffic to the last known good version.

An illustrative pipeline step (verify exact flags against your Wrangler version):

# Capture the active deployment ID before deploy
GOOD_ID=$(wrangler deployments list --name my-worker --json | jq -r '.[0].id')

# Deploy the new version
wrangler deploy --name my-worker

# Run a health check; roll back if it fails
if ! curl -fsS https://my-worker.example.workers.dev/health; then
  wrangler rollback --name my-worker "$GOOD_ID"
fi

What is still uncertain

Cloudflare's deployment history, gradual rollout features, and CI integrations evolve. Treat automatic rollback as unsupported unless current product documentation explicitly lists a health-check or auto-revert setting. Also, Workers for Platforms and service-environment deployments may expose a different API surface than a standalone Worker script.

One diagnostic question: Are you deploying a standalone Worker script or using Workers for Platforms? The answer determines which rollback endpoint and deployment history API you should target.