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.489%Grade C

Incidents

Everything posted on the status page except scheduled maintenance.

211 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.

1h 05m

Longest

Longest Sev 1–2 incident, start to resolved.

44h 29m

Since last

Time since the last counted incident was resolved.

23h 00m

By area

CProduction

16INCIDENTS

2d 19hAFFECTED

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

Worst, 90d

SEV 2Jul 27, 2026 · 3h 27mContinued email delivery errors

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

SEV 2Jul 27, 2026 · 2h 58mElevated errors during email delivery

Most hit

Core Services - AuthKit9

Core Services - SSO2

Supporting Services - Dashboard2

Core Services - Audit Logs1

31 in the last 6 months.

AShipping

6INCIDENTS

6h 56mAFFECTED

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

Worst, 90d

SEV 3Aug 11, 2026 · 1h 22mIntermittent Dashboard sign-in errors

SEV 3Sep 18, 2026 · 40mElevated API Errors

SEV 3Aug 25, 2026 · 1h 05mDashboard sign-in errors

Most hit

Core Services - SSO2

Core Services - AuthKit2

Supporting Services - Dashboard2

Supporting Services - Admin Portal1

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 down14

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

Sev 4 · PapercutDocs, status page, slow dashboard2

When it breaks

Start times, last 12 months, UTC.

Mon

Tue

Wed

Thu

Fri

Sat

Sun

0006121823

What breaks

Core Services - AuthKit21 incidents

Supporting Services - Dashboard10 incidents

Core Services - SSO7 incidents

Core Services - Directory Sync5 incidents

Core Services - Audit Logs2 incidents

Supporting Services - Admin Portal2 incidents

Where it breaks

Last 12 months

Places named on the status page: cloud regions, cities, data centres. Incidents that name none stay off the map.

1 place · 49 with none named

Ohio1

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 35Sev 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 logins, mainly via MIA and ATL points of presence on the US east coast and northern South America.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 · BACK AFTER 11M
Elevated errors and latency hit SSO and AuthKit logins, mainly via MIA and ATL points of presence on the US east coast and northern South America.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 AuthKit had elevated error rates starting around 19:09 UTC on 19 October 2026. The status page reported a partial outage and a fix in progress, and the incident was resolved at 20:21 UTC. No cause was given.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 sign-in requests saw elevated errors, with a partial outage; the text doesn't say how widely customers were hit.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 3

Radar SMS challenge failures for phone numbers in mainland China (+86)WorkOS Radar SMS challenges failed for +86 mainland China numbers starting 17:17 UTC on 2026-10-15. Users missed verification codes or got errors when requesting them. An upstream provider enabled alternate delivery routes, and the issue was resolved by 21:51 UTC.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 3 · REGIONAL · MEDIUM CONFIDENCE
SMS verification codes failed or were not delivered for phone numbers in mainland China for about four and a half hours; other countries were unaffected.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 token exchange and AuthKit sign-in requests returned HTTP 500 errors for about one minute; users could retry.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 token exchange and AuthKit sign-in requests returned HTTP 500 errors for about one minute; users could retry.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 Oct 1, 2026, the Audit Logs API returned HTTP 500 and 408 errors. Some event-creation and export requests failed. An infrastructure change had raised database connections; a fix is being put in place. Events sent without retries may not have been recorded.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 · HIGH CONFIDENCE · BACK AFTER 4M
Audit Logs API returned errors and timeouts for about two minutes; some event writes and exports failed, and other WorkOS products were unaffected.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 one Columbus, Ohio location made some WorkOS API and AuthKit requests fail with HTTP 500 or 403 errors from 11:34 to 11:40 AM EDT. About 8% of requests failed at peak, and up to 21% of audit log event submissions. Events from failed requests were not recorded unless the application retried them. WorkOS systems stayed healthy, and the provider fixed the CDN issue 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 · HIGH CONFIDENCE · DATA LOSS
About 8% of API and AuthKit requests failed for six minutes at one Columbus, Ohio CDN location; other regions were unaffected.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 applications, so about 24% of requests across the public edge returned 5xx errors from 22:40 to 23:03 UTC on September 18. Sign-in was worst hit, along with dashboard and audit log management. Connection recovery was improved afterward.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
AuthKit sign-ins, SSO and API requests failed or stalled across WorkOS for about 23 minutes; the dashboard and management APIs were also hit.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 not reported affected.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
Admin Portal links failed to load for customers without custom domains for about 50 minutes; other customers were not reported affected.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 customersFor about 80 minutes on 9 September 2026, AuthKit form submissions returned HTTP 500 on a small set of custom domains, blocking sign-in for their users. A configuration change caused it; the change 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
Sign-in and other AuthKit form POSTs failed with HTTP 500 on some custom domains for about 80 minutes; the WorkOS API and dashboard were unaffected.
Claude Haiku 5.5 · prompt v10 · 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 for AuthKit failed for end users behind strict network allowlists; 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 for AuthKit failed for end users behind strict network allowlists; other users were not described as affected.
Claude Haiku 5.5 · prompt v10 · 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 limited to upstream testing infrastructure, and the provider reports 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 · MEDIUM CONFIDENCE
Email delivery degradation was limited to upstream testing infrastructure, and the provider reports no external impact.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 elevated errors and timeouts; the text does not say how many users were 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 elevated errors and timeouts; the text does not say how many users were hit.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 25, 20261h 05mSEV 3

Dashboard sign-in errorsUsers could not reliably sign in to the WorkOS Dashboard from about 17:35 to 18:41 UTC due to elevated sign-in errors. A fix was applied at 17:41 and errors were confirmed resolved at 17:54, with the incident closed at 18:41. Customer apps were not described as affected.AI-graded · Supporting Services - Dashboard

Why this grade

RULES · SEV 4
Sev 4 because Supporting Services - Dashboard had a partial outage
CLAUDE · SEV 3 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 19M
Dashboard sign-in errors blocked some users from accessing the WorkOS Dashboard for about an hour; customer apps were not described as affected.
Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record

4 updates

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
17:41 UTC · identified
We have applied a fix and are monitoring the system to verify that Dashboard sign-in is recovering.
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.
18:41 UTC · resolved
This incident is resolved.

Source

Aug 19, 20260mSEV 2

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

Why this grade

RULES · SEV 2
Sev 2 from the incident title (no components listed)
CLAUDE · SEV 2 · SUBSET · HIGH CONFIDENCE
AuthKit authentication endpoints returned HTTP 500 errors for a subset of API requests for about four minutes; recovered automatically.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 15, 202644h 29mSEV 2

Delayed Email DeliverabilityEmails from AuthKit to a subset of Microsoft 365 tenant domains were delivered late, starting August 15 and lasting until August 16. The cause was an upstream email provider incident, and Microsoft implemented mitigations. Delivery was confirmed normal on resolution.AI-graded · regional · Core Services - AuthKit

Why this grade

RULES · SEV 2
Sev 2 because Core Services - AuthKit had degraded performance
CLAUDE · SEV 2 · REGIONAL · MEDIUM CONFIDENCE
Auth emails to a subset of Microsoft 365 tenant domains were delayed for about 37 hours; consumer Outlook domains were not affected.
Claude Haiku 5.5 · prompt v10 · Oct 24, 2026 · Raw record

5 updates

00:24 UTC · investigating
We are seeing deliverability issues with emails sent to Microsoft / Outlook recipients.
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.
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.
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.
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 14, 202631mSEV 2

Delayed Email DeliverabilityAuthKit email delivery was delayed for about 50 minutes for customers without a custom email domain or provider; others were unaffected.AI-graded · some customers · Core Services - AuthKit

Why this grade

RULES · SEV 2
Sev 2 because Core Services - AuthKit had degraded performance
CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE · BACK AFTER 30M
AuthKit email delivery was delayed for about 50 minutes for customers without a custom email domain or provider; others were unaffected.
Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record

3 updates

20:14 UTC · investigating
We're investigating delays in email deliverability.
20:44 UTC · monitoring
We've mitigated the impact and email delivery is returning to normal.
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

Aug 11, 20261h 22mSEV 3

Intermittent Dashboard sign-in errorsIntermittent sign-in failures on the WorkOS Dashboard for about 80 minutes; the text does not describe customer apps being affected.AI-graded · Supporting Services - Dashboard

Why this grade

RULES · SEV 4
Sev 4 because Supporting Services - Dashboard had degraded performance
CLAUDE · SEV 3 · UNCLEAR · MEDIUM CONFIDENCE
Intermittent sign-in failures on the WorkOS Dashboard for about 80 minutes; the text does not describe customer apps being affected.
Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record

2 updates

18:02 UTC · investigating
We are investigating intermittent sign-in failures on the WorkOS Dashboard. We will share an update as soon as possible.
19:24 UTC · resolved
This incident has been resolved.

Source

Aug 5, 202624mNOT COUNTED

Webhook Telemetry IssueProvider reported a false alarm from internal telemetry with no customer impact on webhooks.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 a false alarm from internal telemetry with no customer impact on webhooks.
Claude Haiku 5.5 · prompt v8 · Oct 23, 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 31, 20261h 54mSEV 2

Elevated Authkit SSO ErrorsAuthKit SSO sign-on produced errors and redirect loops for a small subset of customers starting around 16:12 UTC. A fix deployed around 17:10 UTC and the incident was resolved at 18:06 UTC. The standalone SSO API was not affected.AI-graded · some customers · Core Services - SSO +1

Why this grade

RULES · SEV 1
Sev 1 because Core Services - SSO had a partial outage
CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
AuthKit SSO sign-on failed with redirect loops for a small subset of customers for about two hours; standalone SSO was unaffected.
Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record

7 updates

16:01 UTC · investigating
We're investigating an increase in Single Sign-On errors. We will share an update as soon as possible.
16:12 UTC · investigating
It appears some users may be experiencing a redirect loop during sign-on, we are narrowing in on a cause
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.
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
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.
17:10 UTC · monitoring
The fix has deployed, we are monitoring systems to verify the impact is fully mitigated
18:06 UTC · resolved
The issue has been resolved.

Source

Jul 29, 20261h 23mSEV 2

Delayed Email DeliverabilityWorkOS AuthKit emails were delivered late from about 18:30 to 19:25 UTC on July 29, 2026. A mitigation restored normal delivery by 18:36, but dashboard delivery statuses stopped updating until the issue was remediated. The incident was resolved at 19:54 UTC.AI-graded · Core Services - AuthKit

Why this grade

RULES · SEV 2
Sev 2 because Core Services - AuthKit had degraded performance
CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 54M
AuthKit email delivery was delayed for an unspecified scope for about 54 minutes; the dashboard delivery status view also stopped updating.
Claude Haiku 5.5 · prompt v8 · Oct 23, 2026 · Raw record

4 updates

18:30 UTC · investigating
We're investigating delays in email deliverability.
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.
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.
19:54 UTC · resolved
This incident has been resolved.