WorkOS

OPERATIONAL

Since Jan 2026 · 50 incidents · status.workos.com · checked just now

User reports

Visitors who said it's down for them, per hour over 24 hours. Not from the status page. Never counted in grades.

…

Compare Add to stack Status page

GradeCLast 90 days

CPRODASHIP

Overview

30d 90d 1y

Admitted uptime

Customer time not hit, by the provider's own account. Regional and partial incidents count in part.

99.815%Grade A

Incidents

Everything posted on the status page except scheduled maintenance.

61 Sev 1

Fully down

Most customers down, by the provider's own account.

Median fix

Median time to resolve. Half of incidents were fixed faster.

58m

Longest

Longest Sev 1–2 incident, start to resolved.

4h 34m

Since last

Time since the last counted incident was resolved.

37h 54m

By area

AProduction

6INCIDENTS

7h 17mAFFECTED

Your users are hit: apps, APIs, databases, inference

Worst, 30d

SEV 2Oct 19, 2026 · 58mElevated AuthKit Error Rates

SEV 2Oct 15, 2026 · 4h 34m · regionalRadar SMS challenge failures for phone numbers in mainland China (+86)

SEV 2Oct 23, 2026 · 1h 03m · regionalElevated errors across SSO and AuthKit

Most hit

Core Services - AuthKit3

Core Services - SSO1

Supporting Services - Dashboard1

Core Services - Audit Logs1

33 in the last 6 months.

A+Shipping

1INCIDENTS

1h 03mAFFECTED

You can't deploy, build or manage: CI, CLI, dashboard, auth, billing

Worst, 30d

SEV 3Oct 23, 2026 · 1h 03m · regionalElevated errors across SSO and AuthKit

Most hit

Core Services - SSO1

Core Services - AuthKit1

10 in the last 6 months.

CleanSev 3–4Sev 1–2No data

Trend, last 12 months

40 in the last 6 months.

–

Severity mix

Sev 1 · Lights outProd site, API or database down, or data loss1

Sev 2 · BleedingProd degraded or partly down5

Sev 3 · Can't shipCan't deploy, build or manage it0

Sev 4 · PapercutDocs, status page, slow dashboard0

When it breaks

Start times, last 12 months, UTC.

Mon

Tue

Wed

Thu

Fri

Sat

Sun

0006121823

What breaks

Core ServicesAuthKit21 incidents

Supporting ServicesDashboard10 incidents

Core ServicesSSO7 incidents

Core ServicesDirectory Sync5 incidents

Core ServicesAudit Logs2 incidents

Supporting ServicesAdmin Portal2 incidents

Where it breaks

Last 12 months

Places named on the status page: cloud regions, cities, countries, data centres. An incident naming only a broad area (Europe, APAC) is counted under the map, not pinned.

2 places · 48 not pinned

Sev 1–2 time by place, 12 months

Time with a Sev 1 or 2 open that names the place, any provider. Overlaps count once.

China4h 34m

Communication

Updates each

Status page updates per incident, on average.

3.3Last 12 months

Update gap

Median time between status page updates during an incident.

26mLast 12 months

Postmortems

Sev 1–2 incidents with a published write-up.

4 of 40Sev 1–2

Incident history

Show all 50

Oct 23, 20261h 03mSEV 2

Elevated errors across SSO and AuthKitElevated errors and latency hit SSO and AuthKit sign-in for requests served by MIA and ATL, with some US East Coast and northern South America impact.AI-graded · regional · Core Services - SSO +1

Why this grade

RULES · SEV 1
Sev 1 because Core Services - SSO had a partial outage
CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
Elevated errors and latency hit SSO and AuthKit sign-in for requests served by MIA and ATL, with some US East Coast and northern South America impact.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

3 updates

15:57 UTC · investigating
We are seeing elevated errors and request latency across SSO and AuthKit due to network degradation and an upstream provider.
16:09 UTC · monitoring
We're seeing recovery across services and will continue to monitor.
17:01 UTC · 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.

Source

Oct 19, 202658mSEV 2

Elevated AuthKit Error RatesWorkOS saw elevated error rates in AuthKit from about 19:09 to 19:16 UTC on October 19. The issue was identified and a fix was implemented, and the incident was marked resolved about an hour after it started. The text gives no count of affected customers and no root cause.AI-graded · Core Services - AuthKit

Why this grade

RULES · SEV 1
Sev 1 because Core Services - AuthKit had a partial outage
CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
AuthKit error rates were elevated for a short window, about 19:09 to 19:16 UTC, with partial outage on the component; scope not stated.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

4 updates

19:23 UTC · investigating
We are investigating elevated error rates from 19:09 to 19:16 UTC.
19:27 UTC · identified
The issue has been identified and a fix is being implemented.
19:27 UTC · identified
We are continuing to work on a fix for this issue.
20:21 UTC · resolved
This incident has been resolved.

Source

Oct 15, 20264h 34mSEV 2

Radar SMS challenge failures for phone numbers in mainland China (+86)Radar SMS challenges to mainland China (+86) numbers failed or were not delivered, blocking AuthKit verification for those users. An upstream provider enabled alternate delivery routes, and the issue was resolved about four and a half hours after it started.AI-graded · regional · Core Services - AuthKit +1

Why this grade

RULES · SEV 1
Sev 1 because Core Services - AuthKit had a partial outage
CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
Radar SMS verification codes failed or were delayed for phone numbers in mainland China, about four and a half hours, while other countries were unaffected.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

3 updates

17:17 UTC · 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.
17:55 UTC · monitoring
We are seeing some recovery after our upstream provider has enabled alternate delivery routes. We are continuing to monitor.
21:51 UTC · resolved
We've resolved the issue with Radar SMS challenge verifications to China.

Source

Oct 9, 20260mSEV 2

Elevated errors across SSO and AuthKit sign-inSome SSO and AuthKit sign-in requests returned HTTP 500 for about one minute; the provider did not say how many customers were hit.AI-graded

Why this grade

RULES · SEV 1
Sev 1 because the provider reported data loss or exposure
CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
Some SSO and AuthKit sign-in requests returned HTTP 500 for about one minute; the provider did not say how many customers were hit.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

1 update

19:30 UTC · resolved
From 20:20 to 20:21 UTC on October 9, 2026 some SSO and AuthKit sign-in requests failed with HTTP 500 errors. The failures hit SSO token exchange and AuthKit authenticate requests. A database maintenance operation conflicted with live sign-in traffic. The operation self-corrected and service recovered shortly thereafter with no data loss. End users who saw an error could sign in again by retrying. We are updating the maintenance job to avoid live traffic disruption.

Source

Oct 1, 202642mSEV 2

Elevated errors for Audit LogsFor about two minutes on October 1, 2026, the Audit Logs API returned 500 and 408 errors on some event-creation and export requests. An infrastructure change raised database connections; a fix is being deployed. Events sent in that window may be lost if the integration does not retry.AI-graded · one model or feature · Core Services - Audit Logs

Why this grade

RULES · SEV 1
Sev 1 because Core Services - Audit Logs had a partial outage
CLAUDE · SEV 2 · SINGLE · MEDIUM CONFIDENCE · BACK AFTER 4M
Audit Log event creation and some exports returned HTTP 500 and timeout errors for about two minutes; other WorkOS products were unaffected.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

3 updates

21:16 UTC · investigating
We are currently investigating this issue.
21:20 UTC · monitoring
Between 20:39 and 20:41 UTC on October 1, 2026, the Audit Logs API returned elevated errors (HTTP 500 and 408 timeouts) for roughly one minute. Some requests to create audit log events, and a small number of export requests, failed in this window. Requests have succeeded normally since 20:41 UTC. Other WorkOS products were not affected. The incident was triggered by an infrastructure change that increased the number of connections to the database. We have found the cause and are putting a fix in place to prevent it from happening again. If your integration does not retry failed requests, events sent between 20:39 and 20:41 UTC may not have been recorded. We will keep monitoring and post an update once the fix is complete.
21:58 UTC · resolved
This incident has been resolved.

Source

Oct 1, 20260mSEV 1

Elevated API and AuthKit errors for some requests (Columbus, OH region)A CDN network problem at its Columbus, Ohio location caused some WorkOS API and AuthKit requests to fail with HTTP 500 or 403 from 11:34 to 11:40 AM EDT. About 8% of API requests failed at peak, and up to 21% of Audit Logs event submissions failed. Events from failed requests were not recorded unless the app retried them. WorkOS systems stayed healthy and the problem was fixed by 11:40 AM EDT.AI-graded · one location

Why this grade

RULES · SEV 2
Sev 2 from the incident title (no components listed)
CLAUDE · SEV 1 · LOCAL · MEDIUM CONFIDENCE · DATA LOSS
API and AuthKit requests routed through one CDN location in Columbus failed for about 6 minutes; about 8% of API requests failed at peak.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

1 update

15:30 UTC · resolved
On October 1, 2026, from 11:34 to 11:40 AM EDT, our CDN provider had a network problem at its Columbus, Ohio location. Some requests to the WorkOS API (api.workos.com) and to AuthKit-hosted pages failed with HTTP 500 or 403 errors. Only requests routed through that location were affected. At the peak, about 8% of all API requests failed, including Audit Logs event ingestion, authentication and Vault decrypt calls. WorkOS systems stayed healthy the whole time and the provider fixed the problem by 11:40 AM EDT. Audit Logs event ingestion (POST /audit_logs/events) was the most affected endpoint: up to 21% of event submissions failed at the peak. Events from failed requests were not recorded. If your application did not retry them, resend any audit log events submitted between 11:34 and 11:40 AM EDT.

Source

Sep 18, 202640mSEV 2

Elevated API ErrorsA Redis failover left stalled connections in WorkOS application code, exhausting database pools. For about 23 minutes, AuthKit sign-ins, SSO, API calls, dashboard and audit log management requests failed or timed out. Connection recovery was then improved.AI-graded

Why this grade

RULES · SEV 1
Sev 1 from the incident title (no components listed)
CLAUDE · SEV 2 · GLOBAL · HIGH CONFIDENCE · BACK AFTER 20M
Authentication and API requests failed or timed out for about 23 minutes, with sign-in hit hardest; the dashboard and management APIs also erred.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

6 updates

22:49 UTC · investigating
We are investigating an issue with our API. We apologize for the inconvenience and will share an update once we have more information.
23:01 UTC · investigating
We're continuing to investigate this issue to identify the root cause. We'll share another update soon.
23:05 UTC · identified
We've identified the root cause, and we're seeing services are beginning to recover. We'll continue to monitor closely and share updates.
23:09 UTC · monitoring
Our initial remediations are in place, and services have recovered. We're continuing to monitor closely.
23:29 UTC · resolved
Our remediations continue to be effective, and services continue to be recovered. We will continue further investigation and additional preventative measures.
00:53 UTC · postmortem
# Elevated API Errors **Date:** 09/18/2026 **Duration:** 22:40–23:03 UTC \(23 minutes\) **Status:** Resolved ## Summary On September 18, 2026, from 22:40 to 23:03 UTC, WorkOS experienced an outage affecting authentication and other API requests. Customers encountered failed sign-ins, API errors, timeouts, and long delays. Authentication was most severely affected. An infrastructure failover in the cache supporting our feature-flag system exposed weaknesses in application connection recovery and fallback behavior. Some connections remained stalled after the cache was available again, delaying requests and exhausting database connection pools. Service recovered by 23:03 UTC. We subsequently deployed changes to improve connection recovery. We’re sorry for the disruption this caused you and your users. ## Background WorkOS uses feature flags to control application behavior. The affected backend services read flag data from a shared Redis datastore populated by LaunchDarkly Relay. Each application also keeps a local cache, with a 30-second expiration. While an entry is valid, the application can evaluate it locally; after it expires, the application reads Redis. The Redis cluster already had a primary and replica in separate AWS availability zones, with automatic failover enabled. This redundancy allowed AWS to promote a replacement primary. Applications still needed to detect failed connections and reconnect to that primary. ## What Happened ### Affected products Some requests experienced errors or delays across the following products: * **AuthKit:** Sign-in, token requests, user-management operations, and hosted authentication pages. * **Single Sign-On \(SSO\):** Authorization and SAML callback requests. * **WorkOS API:** Selected operations, including organization requests, API-key validation, and connection requests. * **Dashboard:** Some operations that relied on the affected APIs. * **Admin Portal:** Portal link generation and monitored setup requests. * **Directory Sync:** SCIM OAuth token requests, plus delays and client disconnects in Directory Sync API traffic. * **Audit Logs:** Management operations, particularly action-schema creation. ### Customer impact Customer impact lasted from **22:40 to 23:03 UTC**. Across our public edge, **24.1% of recorded requests returned server errors**, and **17.2% ended with the client disconnecting**. The table breaks down request groups by product. | Product | Server errors \(HTTP 5xx\) | Client disconnects \(HTTP 499\) | | --- | --- | --- | | AuthKit, User Management and organization APIs | 37.22% | 24.59% | | Hosted AuthKit \(default-domain proxy\) | 7.27% | 13.77% | | SSO and connection APIs | 2.22% | 2.31% | | Dashboard | 27.10% | 8.08% | | Admin Portal | 24.61% | 7.47% | | Directory Sync APIs | 0.08% | 2.80% | | Audit Logs management APIs | 22.82% | 3.55% | | Audit Logs event capture | 0.0006% | 0.11% | #### Latency Samples * **Authenticate POST requests:** At the peak, one-minute median latency reached approximately 32 seconds and p95 latency reached approximately 45 seconds, compared with roughly 65 ms and 140 ms before the incident. * **Directory Sync:** Peak one-minute p95 latency for selected SCIM user-creation and PATCH-update operations reached approximately 22 seconds, compared with roughly 65 ms before the incident. ### Root cause and contributing factors Around 22:40 UTC, the Redis primary became unavailable to application clients. AWS ElastiCache promoted its replica, completing the failover at 22:40:17 UTC. New connections could reach the promoted node, but some existing application connections remained stalled. Three application behaviors prolonged and amplified the interruption: 1. **Flag-call timeouts did not recover stalled connections.** An application-level deadline returned a fallback value after two seconds, but it did not cancel the underlying Redis command or replace the connection. Additional reads accumulated while clients waited to detect the connection failure. Some commands remained pending for approximately 16 minutes. 2. **External waits held database connections open.** Some flag checks occurred inside database transactions. Repeated waits of several seconds kept pooled database connections occupied and, in some cases, held row locks. Available connections were consumed, causing other requests to queue and fail. Database compute capacity was not the limiting factor. 3. **A fallback selected an incompatible decryption path.** A flag used during a decryption-service migration defaulted to the old behavior when flag evaluation failed. That sent some encrypted values to a legacy service that could not decrypt them, causing additional authentication failures. The local cache reduced normal Redis traffic, but expired entries still depended on Redis. Our two-second deadline limited how long a flag caller waited; it did not provide prompt recovery of a stale, established connection. This was a gap in our resiliency safeguards. ### Recovery and communication Responders restarted affected application instances, which triggered reconnection to the healthy Redis instance. As connections recovered and queued work drained, error rates and latency returned to normal. We also identified a notification gap: the initial status page update did not select the affected service components. Customers subscribed only to those components therefore did not receive the incident notification. ## Timeline All times are UTC. * **September 18, 22:40** — Customer-facing errors and latency increase. AWS completes promotion of the Redis replica at 22:40:17. * **22:44** — Engineers declare an incident following automated alerts. * **22:49** — The public status-page incident is opened. * **22:53** — Investigation identifies stalled feature-flag Redis clients and database connection starvation. * **22:55–23:03** — Responders restart affected application instances, existing clients begin reconnecting, and queued work drains. Recovery progresses across services. * **23:03** — Customer-facing error rates and latency return to normal. * **23:29** — The status-page incident is marked resolved after monitoring. * **September 19, 01:44** — A Redis-client recovery fix is deployed to production after validation with controlled failure and failover tests in staging. ## Remediation ### Immediate Fixes Completed: * **Restored service:** Restarted affected application instances and monitored recovery as clients reconnected and database queues drained. * **Bounded Redis failures:** Deployed a Redis-client change to detect stalled established connections, bound failed operations, and reconnect more promptly. * **Corrected the decryption fallback:** Changed the migration flag’s fallback to behavior compatible with both current and legacy ciphertext formats. * **Validated the recovery fix:** Tested stalled-client behavior and an ElastiCache failover in staging before deploying the connection changes to production. ### Near-term Improvements The following work remains open: * Extend bounded connection recovery to other Redis clients and verify their behavior during failover \(in progress\). * Remove feature-flag and decryption-service network waits from authentication database transactions \(in progress\). * Complete the legacy decryption migration and retire its obsolete flag and fallback paths. * Audit feature-flag defaults against stable production behavior and retire flags whose migrations are complete. * Evaluate and pilot streaming flag updates into application memory, reducing the need to contact Redis while serving requests. ### Preventive Measures Our follow-up work includes: * Improving visibility into flag-evaluation timeouts, fallback use, and connection recovery. * Adding checks for external network waits inside database transactions. * Requiring affected service components to be selected when opening a status-page incident, so component-specific subscribers receive notifications. ## Conclusion We recognize the impact this incident had on you and your customers. We’re sorry for the interruption and for the notification gap. We have deployed the immediate connection-recovery and fallback fixes. We will track the remaining corrective work through completion and update this analysis as unresolved findings are confirmed.

Postmortem Source

Sep 14, 202652mSEV 3

Elevated Admin Portal ErrorsAdmin Portal links failed to load for customers without custom domains for about 50 minutes; other customers were unaffected.AI-graded · some customers · Supporting Services - Admin Portal

Why this grade

RULES · SEV 1
Sev 1 because Supporting Services - Admin Portal had a partial outage
CLAUDE · SEV 3 · SUBSET · MEDIUM CONFIDENCE · BACK AFTER 8M
Admin Portal links failed to load for customers without custom domains for about 50 minutes; other customers were unaffected.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

3 updates

19:08 UTC · investigating
We are investigating an issue loading Admin Portal links for customers without custom domains. We will share more information as soon as it's available.
19:16 UTC · monitoring
We've fixed an issue affecting Admin Portal links for customers without custom domains and are monitoring.
20:00 UTC · resolved
We've resolved an issue loading Admin Portal links for customers without custom domains. If you're still experiencing issues please contact support.

Source

Sep 9, 20262h 02mSEV 2

Form POST failures for some Authkit customersA zone-wide edge header rule was disabled, exposing legacy per-domain rules. For a small set of AuthKit custom domains, server-action form POSTS (sign-in, sign-up, MFA) returned HTTP 500 from about 21:09 to 22:30 UTC. Users could not complete login on affected domains. The configuration was reverted and service restored.AI-graded · some customers · Core Services - AuthKit

Why this grade

RULES · SEV 1
Sev 1 because Core Services - AuthKit had a partial outage, plus 600 points for a security compromise
CLAUDE · SEV 2 · SUBSET · HIGH CONFIDENCE
Form POSTs failed with HTTP 500 for about 16 AuthKit custom domains, roughly 2% of custom-domain traffic, blocking sign-in for about 80 minutes.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

3 updates

21:00 UTC · investigating
We are seeing an elevated error rate for some customers for POST requests. This appears to be limited to a small subset of organizations using custom domains for hosted Authkit
23:02 UTC · resolved
We have identified the source of the problem. A configuration change that applied to roughly 2% of organizations using a custom domain for hosted Authkit resulted in form submission errors. The configuration has been reverted and service restored.
21:10 UTC · postmortem
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 \([[email protected]](mailto:[email protected])\).

Postmortem Source

Sep 2, 20262h 27mSEV 2

Static asset delivery failuresStatic asset delivery failed for end users behind strict network allowlists for about two and a half hours; other users were not described as affected.AI-graded · some customers · Core Services - AuthKit

Why this grade

RULES · SEV 1
Sev 1 because Core Services - AuthKit had a partial outage
CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
Static asset delivery failed for end users behind strict network allowlists for about two and a half hours; other users were not described as affected.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

3 updates

16:39 UTC · identified
We have identified increased failures delivering static assets to end users with strict network allowlists. A fix is in progress.
18:33 UTC · monitoring
We have mitigated the issue and are continuing to monitor.
19:06 UTC · resolved
Static assets delivery rates have recovered.

Source

Aug 31, 202635mNOT COUNTED

Degraded outbound email deliveryEmail delivery degradation was confined to upstream testing infrastructure; the provider says there was no external impact.AI-graded · Core Services - AuthKit

Why this grade

RULES · SEV 2
Sev 2 because Core Services - AuthKit had degraded performance
CLAUDE · SEV 0 · UNCLEAR · HIGH CONFIDENCE
Email delivery degradation was confined to upstream testing infrastructure; the provider says there was no external impact.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

2 updates

14:10 UTC · investigating
We are investigating an issue with successful delivery of emails.
14:45 UTC · resolved
This degradation in delivery was limited to upstream testing infrastructure which has since recovered. There was no external impact.

Source

Aug 27, 202616mSEV 4

Degraded Vault pages in DashboardVault pages in the WorkOS Dashboard showed increased errors and timeouts; the dashboard is slow or partly broken but no API or customer apps were named as hit.AI-graded · Supporting Services - Dashboard

Why this grade

RULES · SEV 4
Sev 4 because Supporting Services - Dashboard had degraded performance
CLAUDE · SEV 4 · UNCLEAR · MEDIUM CONFIDENCE
Vault pages in the WorkOS Dashboard showed increased errors and timeouts; the dashboard is slow or partly broken but no API or customer apps were named as hit.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

2 updates

13:48 UTC · monitoring
Vault pages in the Dashboard started showing increased errors and timeouts starting Aug 26 at 18:00 UTC. We have addressed the issue and are monitoring.
14:04 UTC · resolved
The mitigation is in place and errors rates have returned to normal. We will continue to monitor.

Source

Aug 11–25, 202614d 0hSEV 3

Intermittent Dashboard sign-in errors2 incidents

Tue, Aug 11 18:02 UTC1h 22mSEV 3
Intermittent Dashboard sign-in errorsIntermittent sign-in failures on the WorkOS Dashboard for about 80 minutes; scope and customer count not stated.AI-graded · Supporting Services - Dashboard
Why this grade
1. RULES · SEV 4
  Sev 4 because Supporting Services - Dashboard had degraded performance
2. CLAUDE · SEV 3 · UNCLEAR · MEDIUM CONFIDENCE
  Intermittent sign-in failures on the WorkOS Dashboard for about 80 minutes; scope and customer count not stated.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
1. 18:02 UTC · investigating
  We are investigating intermittent sign-in failures on the WorkOS Dashboard. We will share an update as soon as possible.
2. 19:24 UTC · resolved
  This incident has been resolved.
Source
Tue, Aug 25 17:35 UTC1h 05mSEV 3
Dashboard sign-in errorsUsers could not reliably sign in to the WorkOS Dashboard due to elevated authentication errors. A fix was applied around 17:41 UTC, errors were confirmed resolved by 17:54 UTC, and the incident was closed at 18:41 UTC.AI-graded · Supporting Services - Dashboard
Why this grade
1. RULES · SEV 4
  Sev 4 because Supporting Services - Dashboard had a partial outage
2. CLAUDE · SEV 3 · UNCLEAR · HIGH CONFIDENCE · BACK AFTER 19M
  Dashboard sign-in errors blocked developers from logging into the WorkOS Dashboard for about an hour; customer apps were not described as affected.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
1. 17:35 UTC · investigating
  We are investigating errors affecting sign-in to the WorkOS Dashboard. Users may be unable to authenticate while attempting to access the Dashboard. We will share an update as soon as possible
2. 17:41 UTC · identified
  We have applied a fix and are monitoring the system to verify that Dashboard sign-in is recovering.
3. 17:54 UTC · monitoring
  We have confirmed our fix resolved the elevated errors affecting sign-in to the WorkOS Dashboard and are continuing to monitor.
4. 18:41 UTC · resolved
  This incident is resolved.
Source

Aug 19, 20260mSEV 2

Elevated errors on AuthKit authentication endpointsAuthKit authentication API requests returned HTTP 500 errors for about four minutes; a subset of requests was hit.AI-graded · some customers

Why this grade

RULES · SEV 2
Sev 2 from the incident title (no components listed)
CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
AuthKit authentication API requests returned HTTP 500 errors for about four minutes; a subset of requests was hit.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

1 update

00:00 UTC · resolved
On August 18 from 23:59 to 00:03 UTC (August 19), a subset of API requests (primarily AuthKit authentication endpoints) returned HTTP 500 errors. Automatic maintenance of a large, seldom-used internal index caused brief write-ahead-log contention on a primary database that exhausted connection capacity; service recovered automatically within four minutes. We identified the root cause and removed the index from production at 03:53 UTC on August 19 to prevent recurrence.

Source

Aug 14–16, 20262d 1hSEV 2

Delayed Email Deliverability2 incidents

Fri, Aug 14 20:14 UTC31mSEV 2
Delayed Email DeliverabilityEmail delivery was delayed for AuthKit customers without a custom email domain or provider for about 50 minutes due to an upstream provider issue.AI-graded · some customers · Core Services - AuthKit
Why this grade
1. RULES · SEV 2
  Sev 2 because Core Services - AuthKit had degraded performance
2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE · BACK AFTER 30M
  Email delivery was delayed for AuthKit customers without a custom email domain or provider for about 50 minutes due to an upstream provider issue.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
1. 20:14 UTC · investigating
  We're investigating delays in email deliverability.
2. 20:44 UTC · monitoring
  We've mitigated the impact and email delivery is returning to normal.
3. 20:45 UTC · resolved
  This incident has been resolved. Email delivery was delayed between 15:45 EDT and 16:35 EDT due to an issue with an upstream email service provider. This affected customers who have not yet configured a custom email domain or a custom email provider.
Source
Sat, Aug 15 01:35 UTC44h 29mSEV 2
Delayed Email DeliverabilityAuthKit emails to some Microsoft 365 and Office 365 addresses were delivered late from August 15 until August 16. The cause was an upstream email provider incident, and Microsoft's Outlook team mitigated it. Custom email providers were not affected. Consumer Outlook domains were not described as affected.AI-graded · some customers · Core Services - AuthKit
Why this grade
1. RULES · SEV 2
  Sev 2 because Core Services - AuthKit had degraded performance
2. CLAUDE · SEV 2 · SUBSET · HIGH CONFIDENCE
  Email delivery to a subset of Microsoft 365 tenant domains was delayed for about 1.5 days; other providers and consumer Outlook domains were not described as affected.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
5 updates
1. 00:24 UTC · investigating
  We are seeing deliverability issues with emails sent to Microsoft / Outlook recipients.
2. 01:35 UTC · identified
  We continue to experience deliverability delays to a subset of users with email addresses hosted by Microsoft / Office 365. We are working with our email providers to mitigate the issues, we will provide updates as they become available. Customers using their own custom email providers are not affected.
3. 03:32 UTC · monitoring
  We are observing improvements in deliverability to Microsoft email addresses, in line with the resolution of an incident with our upstream email service provider. We will continue to monitor.
4. 16:21 UTC · identified
  We continue to see email deliverability issues to a subset of Microsoft 365 tenant domains. This does not affect consumer domains such as outlook.com, hotmail.com, live.com or msn.com. We will provide updates as they become available.
5. 22:04 UTC · resolved
  Microsoft's Outlook team has confirmed that mitigations have been implemented. We've verified that email delivery to Microsoft 365 domains is operating normally again. This incident has been resolved.
Source

Aug 5, 202624mNOT COUNTED

Webhook Telemetry IssueProvider reported an internal telemetry issue with no customer impact; treated as a false alarm.AI-graded

Why this grade

RULES · SEV 4
Sev 4 from the incident title (no components listed)
CLAUDE · SEV 0 · UNCLEAR · HIGH CONFIDENCE
Provider reported an internal telemetry issue with no customer impact; treated as a false alarm.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

2 updates

18:04 UTC · investigating
We are investigating an issue with our webhooks. We apologize for the inconvenience and will share an update once we have more information.
18:28 UTC · resolved
This was an issue with our internal telemetry - there is no customer impact. Sorry for the false alarm.

Source

Jul 21–31, 20269d 20hSEV 2

AuthKit SSO failures2 incidents

Tue, Jul 21 21:21 UTC33mSEV 2
AuthKit SSO failuresAuthKit SSO sign-ins failed for customers for about 33 minutes; the text does not say how many customers were hit.AI-graded
Why this grade
1. RULES · SEV 1
  Sev 1 from the incident title (no components listed)
2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 33M
  AuthKit SSO sign-ins failed for customers for about 33 minutes; the text does not say how many customers were hit.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
1. 21:21 UTC · investigating
  We are investigating SSO failures for AuthKit customers.
2. 21:54 UTC · resolved
  We identified and fixed the issue. AuthKit SSO has fully recovered.
Source
Fri, Jul 31 16:12 UTC1h 54mSEV 2
Elevated Authkit SSO ErrorsAuthKit SSO sign-on produced errors and redirect loops for a small subset of customers starting 16:12 UTC on July 31, 2026. Standalone SSO API was unaffected. A fix was deployed around 17:10 UTC and the incident was resolved at 18:06 UTC.AI-graded · some customers · Core Services - SSO +1
Why this grade
1. RULES · SEV 1
  Sev 1 because Core Services - SSO had a partial outage
2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE · BACK AFTER 58M
  AuthKit SSO sign-on failed or looped for a small subset of customers for about two hours; standalone SSO was unaffected.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
7 updates
1. 16:01 UTC · investigating
  We're investigating an increase in Single Sign-On errors. We will share an update as soon as possible.
2. 16:12 UTC · investigating
  It appears some users may be experiencing a redirect loop during sign-on, we are narrowing in on a cause
3. 16:16 UTC · investigating
  We have identifed an issue causing a small subset of Authkit SSO customers to experience errors during sign-on. A fix is being prepared.
4. 16:34 UTC · investigating
  The issue affects a small set of customers using Authkit SSO. The standalone SSO API remains unaffected, we have corrected that here on the status page
5. 17:00 UTC · investigating
  We have identified the issue and are deploying a fix. AuthKit SSO sign-on remains partially degraded for a small subset of customers; standalone SSO continues to be unaffected. We'll share another update once the fix has fully rolled out.
6. 17:10 UTC · monitoring
  The fix has deployed, we are monitoring systems to verify the impact is fully mitigated
7. 18:06 UTC · resolved
  The issue has been resolved.
Source

Jul 27–29, 20262d 9hSEV 2

Elevated errors during email delivery3 incidents

Mon, Jul 27 10:05 UTC2h 58mSEV 2
Elevated errors during email deliveryWorkOS saw elevated errors during email delivery starting 10:05 UTC on 27 July. A mitigation did not fully fix it, a refined mitigation followed, and delivery rates recovered by 13:04 UTC. The text gives no root cause.AI-graded
Why this grade
1. RULES · SEV 1
  Sev 1 from the incident title (no components listed)
2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
  Email delivery through the API showed elevated errors for about three hours; the text does not say how many customers were hit.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
5 updates
1. 10:05 UTC · investigating
  We are investigating elevated errors during delivery of emails.
2. 11:03 UTC · monitoring
  We have implemented a mitigation and are continuing to monitor.
3. 11:20 UTC · investigating
  Our mitigation did not fully resolve the issue. We are continuing to investigate.
4. 12:11 UTC · monitoring
  We have applied a refined mitigation and are continuing to monitor delivery rates.
5. 13:04 UTC · resolved
  Delivery rates have recovered.
Source
Mon, Jul 27 14:10 UTC3h 27mSEV 2
Continued email delivery errorsEmail delivery errors and delayed delivery status updates in the WorkOS Dashboard, starting 14:10 UTC on July 27. Delivery rates recovered at 15:36 and the incident was resolved at 17:37. The text gives no cause and does not say how many customers were affected.AI-graded · Supporting Services - Dashboard
Why this grade
1. RULES · SEV 4
  Sev 4 because Supporting Services - Dashboard had a partial outage
2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 1H 26M
  Email delivery errors hit sends for an unstated share of customers for about three hours; the dashboard's delivery statuses also stopped updating.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
1. 14:10 UTC · investigating
  We are investigating reports that email delivery statuses in Dashboard are not being updated.
2. 14:33 UTC · investigating
  We are continuing to investigate email delivery errors in addition to Dashboard email delivery statuses not being updated.
3. 15:36 UTC · monitoring
  We have remediated the issue. Email delivery rates have recovered and reported email delivery status in Dashboard are being updated properly. We are continuing to monitor.
4. 17:37 UTC · resolved
  Email delivery is operating normally.
Source
Wed, Jul 29 18:30 UTC1h 23mSEV 2
Delayed Email DeliverabilityAuthKit email delivery was delayed from about 18:30 to 19:24 UTC on July 29, 2026. A mitigation restored normal delivery rates by 18:36, but the dashboard's delivery statuses were not updated until the 19:24 remediation. Monitoring continued until resolution at 19:54.AI-graded · Core Services - AuthKit
Why this grade
1. RULES · SEV 2
  Sev 2 because Core Services - AuthKit had degraded performance
2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 54M
  AuthKit email deliveries were delayed for about an hour; the text does not say how many customers were hit.
3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
1. 18:30 UTC · investigating
  We're investigating delays in email deliverability.
2. 18:36 UTC · identified
  We've identified the issue and have implemented a mitigation. We are seeing normal email deliverability now but Dashboard email delivery statuses are currently not being updated.
3. 19:24 UTC · monitoring
  We have remediated the issue. Email delivery rates have recovered and reported email delivery status in Dashboard are being updated properly. We are continuing to monitor.
4. 19:54 UTC · resolved
  This incident has been resolved.
Source

Jul 27, 20262h 04mSEV 2

Webhook Delivery DelaysWebhook deliveries were delayed from about 19:09 to 20:54 UTC on July 27, 2026. The cause was identified as processing latency, and a fix was rolled out. Delivery times returned to normal by 20:54, and the incident was closed at 21:12.AI-graded

Why this grade

RULES · SEV 2
Sev 2 from the incident title (no components listed)
CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 1H 46M
Webhook deliveries to customer apps were delayed for about two hours; the text does not say how many customers were hit.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

6 updates

19:09 UTC · investigating
We're investigating delays in webhook delivery. We will share an update as soon as possible.
19:36 UTC · identified
We have identified the cause of the delays in webhook delivery and are rolling out a fix to reduce processing latency.
20:34 UTC · identified
We have rolled out a fix and are seeing improvements to webhook delivery times. We will provide another update soon.
20:54 UTC · monitoring
We have confirmed that webhook delivery times are back to normal levels. We are continuing to monitor.
21:11 UTC · monitoring
This has been resolved.
21:12 UTC · resolved
This incident has been resolved.

Source

Jul 22, 20261h 16mSEV 2

Email Delivery DelaysWorkOS investigated delayed email delivery starting 01:35 UTC on 22 July 2026. They identified the issue, remediated it, and saw delivery recover by 02:19. The incident was resolved at 02:51 UTC.AI-graded

Why this grade

RULES · SEV 2
Sev 2 from the incident title (no components listed)
CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
Email delivery was delayed for WorkOS customers for about an hour; the text does not say how many were hit.
Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record

4 updates

01:35 UTC · investigating
We're investigating possible email delivery delays.
02:16 UTC · identified
We've identified the issue and are implementing remediations.
02:19 UTC · monitoring
We've remediated the issue and are seeing email delivery recover.
02:51 UTC · resolved
This has been resolved.