From November 13 to November 14, 2026, the Cloudflare Workers API returned 5xx errors — wrangler deploy and other Workers API actions failed, while already-deployed Workers kept running. Cloudflare implemented a fix on November 13 and resolved the incident on November 14 at 13:37 UTC. Deploys work again — if yours still fails, it is a new problem, not the incident.
Quick Fix Summary
- Problem: From November 13 to November 14, 2026, the Cloudflare Workers API returned 5xx errors —
wrangler deployand other Workers API actions failed, while already-deployed Workers kept running.- Fix: None user-side. Cloudflare resolved the incident on November 14 at 13:37 UTC. If your deploy still fails now, check cloudflarestatus.com to confirm the resolution, then deploy once — the failure is no longer the incident.
- What happened: Cloudflare status incident “Cloudflare is seeing an issue with Workers API availability” — investigating 15:31 UTC Nov 13, identified 15:39 UTC, fix implemented 15:42 UTC, resolved 13:37 UTC Nov 14. No cause published by Cloudflare.
Technical Root Cause
| Error Code | Affected Version | Root Cause | Current Status |
|---|---|---|---|
| 5xx errors on Workers API actions (no narrower code published) | Cloudflare Workers API — deploys and other Workers API actions; already-deployed Workers keep running | Not published by Cloudflare beyond the status updates | Resolved November 14, 2026, 13:37 UTC (started Nov 13, 15:31 UTC) |
Step-by-Step: What to Do When Workers Deploys Fail With 5xx
Step 1 — Check Cloudflare’s Status Page First
Open https://www.cloudflarestatus.com and look for the Workers API incident. While it was open, deploys failed whatever you changed locally — the API itself was returning 5xx errors. It is resolved now (November 14, 13:37 UTC), so a deploy that still fails is a new problem, not the incident. This is the same first move as our Fix: ChatGPT Work Mode HTTP 500 Error — when the vendor’s status page shows an incident, stop troubleshooting your own setup.
Step 2 — Confirm It Is the API, Not Your Code
Check whether your already-deployed Worker still serves traffic: open the dashboard Logs or run wrangler tail and watch live requests. If the live Worker responds normally while deploys fail, your code is fine — only the API that publishes new versions is broken.
wrangler tailStep 3 — Do Not Hammer wrangler deploy
During the incident, re-running the deploy again and again did not help — every attempt hit the same failing API, and repeated failed deploys left you unsure which version was live. The incident is resolved now, so deploy once and confirm the new version.
wrangler deployStep 4 — Deploy Once Now That the Incident Has Cleared
The status page now marks the incident resolved (November 14, 13:37 UTC), so check which version is actually live before redeploying:
wrangler deployments listThen deploy once and confirm the new version. If a deploy still fails now, that is a new problem — check your build output and wrangler logs before redeploying again. The same discipline applied to the ChatGPT Sites publishing failure we covered in Fix: ChatGPT Sites Publishing Failing — one retry after resolution, then investigate.
Step 5 — Note the Same Morning’s Companion Incident
November 14 was a bad morning for Cloudflare in general: a separate “Increased errors for R2 and Tiered Cache” incident ran 05:30–06:45 UTC (resolved, 1 hour 15 minutes) — a network connectivity issue between data centers caused R2 HTTP 500 errors and Tiered Cache 520/522/524 errors. It is resolved and narrower than the Workers API incident, but it shows the same morning’s network trouble.
Before you retry a deploy, make sure your code is safe
A failed deploy should never be the moment you discover your code only lives on one laptop. Commit to git, and keep a full-drive backup — Acronis Cyber Protect images the whole drive — so a bad deploy day costs you minutes, not your work. (Affiliate link — DebugRadar earns a commission if you sign up through it.)
Cloud trouble didn’t stop at Workers: a Supabase database incident left some databases unavailable the same week, and Outlook mail kept arriving late for days after the Microsoft 365 outage. See Fix: Supabase Database Connection Errors and Fix: Outlook Emails Still Delayed After Outage.
FAQ
Are my deployed Workers down?
No. The incident hits the Workers API — deploys and other API actions fail with 5xx errors. Workers that are already deployed keep serving traffic. Check the dashboard or wrangler tail: if your live Worker still responds, your code is fine.
Why does wrangler deploy keep failing?
During the incident, the Workers API itself returned 5xx errors, so every deploy attempt hit the same failing API. The incident is resolved as of November 14, 13:37 UTC — if deploys still fail now, check the status page and your build output; it is a new problem, not the incident.
What should I check before redeploying?
The status page has cleared — the incident resolved November 14, 13:37 UTC. Run wrangler deployments list to see which version is actually live, then deploy once and confirm the new version. If a deploy still fails now, that is a new problem — check your build output and wrangler logs before redeploying again.
Sources: Cloudflare status page (cloudflarestatus.com), November 13–14, 2026; Pingoru Cloudflare timeline; GetUptimely Cloudflare status, November 14, 2026.
Verified by DebugRadar Engineering — Tested on Production Environments
DebugRadar’s engineering team tracks this issue against the vendor’s official status page and reproduces the reported failure before publishing. If the vendor resolves it, we update the guide — check the status links above for the latest state.