Affected Components:

Nov 10, 01:53:58 GMT+0
Investigating - Changes to Cloudflare Workers are temporarily not producing Event Subscription events. We have intentionally disabled this feature due to an on-going issue. We are actively working to restore it, but this, regrettably, may take a while. Changes to Workers themselves are working normally. Already deployed Workers are entirely unaffected..

Duration: 23 days, 19 hours and 2 minutes

Affected Components:

Nov 10, 01:46:28 GMT+0
Resolved - This incident has been resolved..

Nov 9, 16:35:55 GMT+0
Monitoring - We are continuing to monitor for any further issues..

Nov 9, 16:22:38 GMT+0
Identified - We are continuing to work on a fix for the issue..

Nov 9, 16:15:26 GMT+0
Investigating - Cloudflare is aware of and investigating issues related to creating, editing and deleting Workers. Impact is limited to changing Workers — Workers that are already deployed are unaffected..

Duration: 10 days and 19 hours

Affected Components:

Nov 8, 00:10:40 GMT+0
Resolved - This incident has been resolved..

Nov 8, 00:02:08 GMT+0
Monitoring - Our upstream provider has mitigated the issue affecting those edge regions and 503 error rates have returned to normal..

Nov 7, 23:24:30 GMT+0
Identified - We continue to see intermittent 503 errors on a small fraction of requests routed through Ashburn, Virginia. We continue to work with the upstream provider..

Nov 7, 21:24:14 GMT+0
Identified - We continue to see intermittent 503 errors on a small fraction of requests routed through certain regions, primarily Ashburn, Virginia. We will provide updates as they become available while we work with our upstream provider..

Nov 7, 19:51:40 GMT+0
Identified - We're seeing intermittent 503 errors on a small fraction of requests routed through certain regions, primarily Ashburn, Virginia. We've isolated this to an issue with an upstream provider and are working with them on a resolution..

Duration: 2 days and 59 minutes

Affected Components:

Nov 2, 17:30:10 GMT+0
Resolved - This incident has been resolved..

Nov 2, 16:41:11 GMT+0
Identified - Some customers may see delays when deploying updates to Cloudflare Workers. Remediation is in progress..

Affected Components:

Oct 29, 09:24:20 GMT+0
Investigating - Cloudflare is investigating an issue where success rates and SLIs for Workflows operations have been dipping since approximately 07:00 UTC. Customers may experience increased errors or failures when running workflows. Our team is actively investigating the root cause to restore normal service..

Duration: 8 days, 14 hours and 28 minutes

Affected Components:

Oct 27, 01:15:15 GMT+0
Resolved - This incident has been resolved..

Oct 27, 00:55:17 GMT+0
Monitoring - We are continuing to monitor for any further issues..

Oct 26, 21:48:46 GMT+0
Investigating - We are investigating reports that some Workers Cron Triggers are running late, being skipped, or running more than once. Affected customers may see scheduled Workers invocations that do not run on time or run more than once. We will post an update as we learn more..

Duration: 2 days, 15 hours and 13 minutes

Affected Components:

Oct 23, 17:01:08 GMT+0
Resolved - This is now resolved. Errors and latency were elevated between 15:21 and 15:50 UTC primarily for requests served by MIA and ATL with some impact on the US east coast and northern South America..

Oct 23, 16:09:18 GMT+0
Monitoring - We're seeing recovery across services and will continue to monitor..

Oct 23, 15:57:55 GMT+0
Investigating - We are seeing elevated errors and request latency across SSO and AuthKit due to network degradation and an upstream provider..

Duration: 12 days, 21 hours and 32 minutes

Affected Components:

Oct 23, 20:37:06 GMT+0
Resolved - This incident has been resolved..

Oct 23, 20:29:51 GMT+0
Monitoring - A fix has been implemented and we are monitoring the results..

Oct 23, 15:27:34 GMT+0
Investigating - We are investigating reports that some Workers Cron Triggers are running late, being skipped, or running more than once. Affected customers may see scheduled Workers invocations that do not run on time or run more than once. We will post an update as we learn more..

Duration: 1 day, 5 hours and 55 minutes

Affected Components:

Oct 22, 17:31:27 GMT+0
Resolved - This incident has been resolved..

Oct 22, 17:01:31 GMT+0
Investigating - We are investigating elevated error rates (HTTP 502) for some requests handled by our Ashburn, Virginia data center. Some customers may see failed or intermittent responses for websites and applications, including Workers, served through this location. We are actively investigating and will provide updates as we learn more..

Duration: 1 day, 18 hours and 35 minutes

Affected Components:

Oct 22, 16:15:52 GMT+0
Resolved - This incident has been resolved..

Oct 22, 16:04:05 GMT+0
Monitoring - We are continuing to monitor for any further issues..

Oct 22, 15:33:17 GMT+0
Identified - Cloudflare is investigating an increased latency when interacting with Workers API and Workers configuration in the dashboard. Customers might experience longer wait times on Workers endpoints, particularly when deploying a script. Workers that are already running in production are not affected. More updates to follow shortly..

Duration: 2 days, 9 hours and 56 minutes

Affected Components:

Oct 19, 20:21:30 GMT+0
Resolved - This incident has been resolved..

Oct 19, 19:27:33 GMT+0
Identified - We are continuing to work on a fix for this issue..

Oct 19, 19:27:07 GMT+0
Identified - The issue has been identified and a fix is being implemented..

Oct 19, 19:23:33 GMT+0
Investigating - We are investigating elevated error rates from 19:09 to 19:16 UTC..

Duration: 2 days, 16 hours and 37 minutes

Affected Components:

Oct 16, 01:06:26 GMT+0
Resolved - Workers Cron Triggers have stabilized.

Oct 16, 00:54:53 GMT+0
Monitoring - We are continuing to monitor for any further issues..

Oct 16, 00:01:49 GMT+0
Identified - Cloudflare is investigating issues with Workers Cron Triggers. A subset of customers may not be having their cron get invoked. We are working to mitigate this problem. More updates to follow shortly..

Duration: 11 days, 10 hours and 7 minutes

Affected Components:

Oct 15, 21:51:42 GMT+0
Resolved - We've resolved the issue with Radar SMS challenge verifications to China..

Oct 15, 17:55:32 GMT+0
Monitoring - We are seeing some recovery after our upstream provider has enabled alternate delivery routes. We are continuing to monitor..

Oct 15, 17:17:35 GMT+0
Investigating - We are investigating an issue affecting Radar SMS challenge verification for phone numbers in mainland China (+86). Affected users may not receive verification codes or may encounter an error when requesting one, preventing them from completing verification. We will provide an update as more information becomes available..

Duration: 18 days, 17 hours and 27 minutes

Affected Components:

Oct 15, 01:29:39 GMT+0
Resolved - Workers Cron Trigger backlogs have cleared and appear healthy. Cron Trigger schedules should be executing as expected. Some schedule redeploys may be required for a small fraction of Workers who were impacted during the incident..

Oct 14, 08:14:16 GMT+0
Monitoring - We are continuing to monitor for any further issues..

Oct 14, 07:23:21 GMT+0
Identified - A fix has been identified and is underway.

Oct 14, 05:36:12 GMT+0
Investigating - Cloudflare is investigating issues with Workers Cron Triggers. Customers who have recently created or modified a Cron Trigger schedule may find that the schedule is not executing as expected. Pre-existing Cron Trigger schedules that have not been recently modified are not affected. We are working to identify the cause and mitigate this problem. More updates to follow shortly..

Duration: 22 days, 3 hours and 25 minutes

Affected Components:

Oct 14, 00:09:26 GMT+0
Resolved - This incident has been resolved..

Oct 13, 23:10:18 GMT+0
Monitoring - We are continuing to monitor for any further issues..

Oct 13, 15:19:04 GMT+0
Identified - The issue has been identified and a fix is being implemented..

Oct 13, 15:18:01 GMT+0
Investigating - Cloudflare is investigating issues with Workers Cron Triggers. Customers who have recently created or modified a Cron Trigger schedule may find that the schedule is not executing as expected. Pre-existing Cron Trigger schedules that have not been recently modified are not affected. We are working to identify the cause and mitigate this problem. More updates to follow shortly..

Duration: 7 days, 22 hours and 55 minutes

Affected Components:

Oct 12, 22:20:15 GMT+0
Resolved - This incident has been resolved..

Oct 12, 19:39:43 GMT+0
Monitoring - A fix has been implemented and we are monitoring the results..

Oct 12, 19:09:20 GMT+0
Investigating - Cloudflare is investigating issues with Workers Cron Triggers. Customers who have recently created or modified a Cron Trigger schedule may find that the schedule is not executing as expected. Pre-existing Cron Trigger schedules that have not been recently modified are not affected. We are working to identify the cause and mitigate this problem. More updates to follow shortly..

Duration: 1 day, 9 hours and 8 minutes

Affected Components:

Oct 12, 14:05:20 GMT+0
Resolved - This incident has been resolved..

Oct 12, 13:42:46 GMT+0
Monitoring - A fix has been implemented and we are monitoring the results..

Oct 12, 13:32:12 GMT+0
Investigating - Cloudflare is investigating 504s errors when interacting with Workers API and Workers configuration in the dashboard. Customers might experience some unavailability on Workers endpoints, particularly when deploying a script. Workers that are already running in production are not affected. More updates to follow shortly..

Duration: 1 hour

Affected Components:

Oct 10, 15:29:14 GMT+0
Completed - The scheduled maintenance has been completed..

Oct 10, 15:23:11 GMT+0
Identified - Verification is currently underway for the maintenance items..

Oct 10, 15:00:10 GMT+0
Identified - Scheduled maintenance is currently in progress. We will provide updates as necessary..

Oct 10, 14:00:18 GMT+0
Planned - Maintenance will begin as scheduled in 60 minutes..

Oct 7, 13:10:44 GMT+0
Planned - WorkOS will be undergoing a required platform upgrade on Saturday, October 10th starting at 15:00 UTC and ending at 16:00 UTC. Within this window, we expect a single period of increased latency and error rate lasting up to 2 minutes across all WorkOS products, including event and webhook delivery. Events and webhooks generated during this period may be delayed. If you have any questions, please reach out to support@workos.com.

Duration: 5 days, 1 hour and 37 minutes

Affected Components:

Sep 16, 21:10:31 GMT+0
Resolved - We're sorry for the disruption this incident caused for you and your users. Authentication is a critical path, and during this window we did not meet the reliability standard you expect from WorkOS. We take responsibility for the impact. Service was restored the same day, and we have already shipped several lasting fixes while continuing broader cleanup and detection work. # Postmortem: AuthKit custom domain sign-in failures **Date:** September 9, 2026 **Duration:** 21:09 – 22:30 UTC \(~80 minutes of customer impact\) **Status:** Resolved ## Summary On September 9, 2026, from approximately **21:09 to 22:30 UTC**, a small subset of customers using **AuthKit custom domains** experienced failures when submitting authentication forms \(sign-in, sign-up, MFA verification, device authorization, and email verification\). Users on affected domains saw **HTTP 500** errors on those form submissions, which blocked interactive login for the duration of the incident. This was a **partial outage**. It affected a small cohort of AuthKit custom domains provisioned through an earlier self-serve configuration path—**about 0.17%** of AuthKit custom-domain traffic was actually affected by the failure. Default AuthKit domains \(`*.authkit.app`\), the WorkOS API, the Dashboard, and **GET** requests \(page loads and most OAuth callback traffic\) on custom domains continued to work. The failure mode was specific to **server-action POST** requests used by AuthKit hosted UI forms. We first learned of the issue from a customer report at approximately **22:04 UTC** \(~55 minutes after impact began\). Engineering restored service by **22:30 UTC**. No evidence of unauthorized access, data exposure, or data corruption was found. ## Background AuthKit can be hosted on a customer’s own hostname \(a **custom domain**\). Traffic for those hostnames is terminated at our edge and forwarded to the AuthKit application with HTTP headers that identify the original host and browser origin. The AuthKit application relies on those headers so that browser security checks for interactive form submissions \(Next.js server actions\) succeed. Over time, WorkOS evolved how custom-domain traffic is routed at the edge—from earlier **per-domain** configuration toward shared, list-based edge rules and a newer application hosting path. During that migration, a set of **legacy per-domain header rules** remained in place for domains created in an earlier era. A later **zone-wide** edge rule normally overwrote those headers so the application always saw a consistent, CSRF-safe origin. While that zone-wide rule was enabled, the older per-domain rules appeared inert. ## What happened As part of decommissioning older edge configuration no longer needed for the current hosting path, the zone-wide header transform rule was **disabled** in production. That change unmasked the leftover per-domain rules for the older custom-domain cohort. For those domains, the edge continued to rewrite the browser `Origin` header to the tenant’s default AuthKit hostname, while the application still received the customer’s custom hostname as the forwarded host. AuthKit’s application layer correctly rejected the mismatched server-action POSTs as invalid \(CSRF / same-origin protection\), returning HTTP 500 before application business logic ran. **Scope** * Structurally exposed: AuthKit custom domains still carrying the legacy per-domain header configuration \(on the order of a few dozen hostnames\). * Observed traffic impact: a subset of those domains that received form POST traffic during the window \(about sixteen hostnames with material volume\). * Scale: roughly **2%** of AuthKit custom-domain traffic comes from potentially affected domains; **~3,100** failed server-action POSTs over the ~80-minute window. For affected domains, failure rates on form POSTs were often near **100%**. **Symptoms** * Users on affected custom domains could not complete interactive AuthKit forms \(sign-in and related flows\). * Default AuthKit hostnames and non-form traffic paths remained healthy. **What went wrong** The proximate trigger was disabling a shared edge header rule that had been **silently correcting** residual per-domain header rewrites left over from an earlier custom-domain design. The durable underlying condition was incomplete cleanup of that legacy configuration after the supported path moved to list-based rules—and the absence of automated detection for this failure shape. **Why it wasn’t caught sooner** Several detection gaps stacked: 1. Pre-change validation and canaries primarily covered **newer** custom domains \(and often **GET** probes\). This failure only appears on **server-action POSTs** for the legacy cohort, with no representation of this configuration in our validation environment. 2. Aggregate AuthKit error rates stayed relatively low because only a small share of traffic was affected, so fleet-wide thresholds did not page. As a result, detection depended on customer reports rather than an automated page. ## Remediation ### Completed since the incident * **Worker safety net** — Added application-edge protection that detects and drops stale per-domain origin values so legacy rules can be retired without recreating this mismatch, even if rule order differs. * **Staging validation path** — Reproduced the legacy custom-domain configuration in staging so further edge cleanup can be proven safe before production changes. ### In progress / planned * **Remove legacy per-domain edge rules** for AuthKit custom domains after staged validation, so shared transform rules are no longer load-bearing masks. * **Inventory residual edge configuration** tied to custom domains \(including orphaned rules\) so leftover resources have clear ownership and review. * **Per-customer / concentrated-failure detection** so a small set of fully down tenants is visible even when fleet-wide error rates look healthy. * **Stronger change gates** for catch-all / list edge-rule changes: same-phase inventory of earlier rules that can match the same hosts, and canaries that include **legacy-era domains** and **server-action POST** probes—not only GET checks on newer domains. * **Improved change visibility** for production edge-rule state \(today some zone rules are dashboard-managed without a PR trail\). We treat restoring the shared transform as necessary containment, not the durable end state. The combination of residue removal, better probes, and better detection is intended to prevent both recurrence of this exact mechanism and silent customer-total failures on a small hostname set. ## Closing A configuration cleanup on the AuthKit custom-domain edge path exposed leftover rules from an earlier design and blocked interactive sign-in for a limited set of custom domains for about eighty minutes. We restored service quickly once the issue was identified, and we are following through so legacy edge residue cannot remain load-bearing, so validation covers the domains and request types that actually break, and so concentrated authentication failures are visible to us before they are visible only to your users. We regret the impact on affected customers and their end users, and we appreciate the reports that helped us engage. If you have questions about whether your integration was in the affected cohort, please contact WorkOS support \([support@workos.com](mailto:support@workos.com)\)..

Affected Components:

Sep 12, 03:34:16 GMT+0
Resolved - This incident has been resolved..

Sep 12, 02:25:01 GMT+0
Monitoring - A fix has been implemented and we are monitoring the results..