Dev APIs / Auth / WorkOS

WorkOS

OPERATIONAL

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

User reportsVisitors who said it's down for them, per hour over 24 hours. Not from the status page. Never counted in grades.
…
CompareAdd to stackStatus page
GradeCLast 90 days
CPRODASHIP

Overview

30d90d1y
Admitted uptimeCustomer time not hit, by the provider's own account. Regional and partial incidents count in part.
99.417%Grade C
IncidentsEverything posted on the status page except scheduled maintenance.
211 Sev 1
Fully downMost customers down, by the provider's own account.
0m
Median fixMedian time to resolve. Half of incidents were fixed faster.
1h 05m
LongestLongest Sev 1–2 incident, start to resolved.
44h 29m
Since lastTime since the last counted incident was resolved.
37h 54m

By area

CProduction
17INCIDENTS
2d 21hAFFECTED
Your users are hit: apps, APIs, databases, inference
Worst, 90d
SEV 2Jul 27, 2026 · 2h 04mWebhook Delivery Delays
SEV 2Jul 27, 2026 · 3h 27mContinued email delivery errors
SEV 2Oct 19, 2026 · 58mElevated AuthKit Error Rates
Most hit
Core Services - AuthKit9
Core Services - SSO2
Supporting Services - Dashboard2
Core Services - Audit Logs1
33 in the last 6 months.
AShipping
6INCIDENTS
7h 04mAFFECTED
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 9, 2026 · 2h 02m · some customersForm POST failures for some Authkit customers
SEV 3Sep 18, 2026 · 40mElevated API Errors
Most hit
Core Services - AuthKit2
Supporting Services - Dashboard2
Core Services - SSO1
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 down16
Sev 3 · Can't shipCan't deploy, build or manage it3
Sev 4 · PapercutDocs, status page, slow dashboard1

When it breaks

Start times, last 12 months, UTC.

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 monthsPlaces 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
China: 1 incident · WorkOSOhio: 1 incident · WorkOS
Sev 1–2 time by place, 12 monthsTime with a Sev 1 or 2 open that names the place, any provider. Overlaps count once.
China4h 34m

Communication

Updates eachStatus page updates per incident, on average.
3.3Last 12 months
Update gapMedian time between status page updates during an incident.
26mLast 12 months
PostmortemsSev 1–2 incidents with a published write-up.
4 of 40Sev 1–2

Incident history

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
  1. RULES · SEV 1
    Sev 1 because Core Services - SSO had a partial outage
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 15:57 UTC · investigating
    We are seeing elevated errors and request latency across SSO and AuthKit due to network degradation and an upstream provider.
  2. 16:09 UTC · monitoring
    We're seeing recovery across services and will continue to monitor.
  3. 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
  1. RULES · SEV 1
    Sev 1 because Core Services - AuthKit had a partial outage
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
  1. 19:23 UTC · investigating
    We are investigating elevated error rates from 19:09 to 19:16 UTC.
  2. 19:27 UTC · identified
    The issue has been identified and a fix is being implemented.
  3. 19:27 UTC · identified
    We are continuing to work on a fix for this issue.
  4. 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
  1. RULES · SEV 1
    Sev 1 because Core Services - AuthKit had a partial outage
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 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.
  2. 17:55 UTC · monitoring
    We are seeing some recovery after our upstream provider has enabled alternate delivery routes. We are continuing to monitor.
  3. 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
  1. RULES · SEV 1
    Sev 1 because the provider reported data loss or exposure
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
1 update
  1. 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
  1. RULES · SEV 1
    Sev 1 because Core Services - Audit Logs had a partial outage
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 21:16 UTC · investigating
    We are currently investigating this issue.
  2. 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.
  3. 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
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
1 update
  1. 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
  1. RULES · SEV 1
    Sev 1 from the incident title (no components listed)
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
6 updates
  1. 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.
  2. 23:01 UTC · investigating
    We're continuing to investigate this issue to identify the root cause. We'll share another update soon.
  3. 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.
  4. 23:09 UTC · monitoring
    Our initial remediations are in place, and services have recovered. We're continuing to monitor closely.
  5. 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.
  6. 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.
PostmortemSource
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
  1. RULES · SEV 1
    Sev 1 because Supporting Services - Admin Portal had a partial outage
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 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.
  2. 19:16 UTC · monitoring
    We've fixed an issue affecting Admin Portal links for customers without custom domains and are monitoring.
  3. 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
  1. RULES · SEV 1
    Sev 1 because Core Services - AuthKit had a partial outage, plus 600 points for a security compromise
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 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
  2. 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.
  3. 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])\).
PostmortemSource
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
  1. RULES · SEV 1
    Sev 1 because Core Services - AuthKit had a partial outage
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 16:39 UTC · identified
    We have identified increased failures delivering static assets to end users with strict network allowlists. A fix is in progress.
  2. 18:33 UTC · monitoring
    We have mitigated the issue and are continuing to monitor.
  3. 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
  1. RULES · SEV 2
    Sev 2 because Core Services - AuthKit had degraded performance
  2. CLAUDE · SEV 0 · UNCLEAR · HIGH CONFIDENCE
    Email delivery degradation was confined to upstream testing infrastructure; the provider says there was no external impact.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
  1. 14:10 UTC · investigating
    We are investigating an issue with successful delivery of emails.
  2. 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
  1. RULES · SEV 4
    Sev 4 because Supporting Services - Dashboard had degraded performance
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
  1. 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.
  2. 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
  1. 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
  2. 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
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    AuthKit authentication API requests returned HTTP 500 errors for about four minutes; a subset of requests was hit.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
1 update
  1. 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
  1. 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
  2. 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
  1. RULES · SEV 4
    Sev 4 from the incident title (no components listed)
  2. CLAUDE · SEV 0 · UNCLEAR · HIGH CONFIDENCE
    Provider reported an internal telemetry issue with no customer impact; treated as a false alarm.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
  1. 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.
  2. 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
  1. 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
  2. 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
  1. 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
  2. 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
  3. 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
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
6 updates
  1. 19:09 UTC · investigating
    We're investigating delays in webhook delivery. We will share an update as soon as possible.
  2. 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.
  3. 20:34 UTC · identified
    We have rolled out a fix and are seeing improvements to webhook delivery times. We will provide another update soon.
  4. 20:54 UTC · monitoring
    We have confirmed that webhook delivery times are back to normal levels. We are continuing to monitor.
  5. 21:11 UTC · monitoring
    This has been resolved.
  6. 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
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. 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.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
  1. 01:35 UTC · investigating
    We're investigating possible email delivery delays.
  2. 02:16 UTC · identified
    We've identified the issue and are implementing remediations.
  3. 02:19 UTC · monitoring
    We've remediated the issue and are seeing email delivery recover.
  4. 02:51 UTC · resolved
    This has been resolved.
Source
Jul 21, 202651mSEV 2
Elevated Webhook LatencyWorkOS webhook deliveries were delayed starting around 18:58 UTC on 2026-07-21. The provider identified the source of the latency and implemented a fix. Latency returned to normal by 19:37 and the incident was resolved at 19:49, affecting only a very small subset of customers.AI-graded · some customers
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    Webhook delivery to customer apps was delayed for a very small subset of customers for about 50 minutes.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
  1. 18:58 UTC · investigating
    We're investigating webhook delivery delays. We apologize for the inconvenience and will share an update once we have more information.
  2. 19:09 UTC · identified
    We've identified the source of the latency and have implemented a fix.
  3. 19:37 UTC · monitoring
    We're seeing a return to normal webhook latency and are continuing to monitor.
  4. 19:49 UTC · resolved
    Webhook latency is back to normal levels. We have identified that this latency only affected a very small subset of customers.
Source
Jul 16, 202615mSEV 2
Email delivery delaysEmail delivery was delayed for AuthKit customers for about 15 minutes; the text does not say how many were hit.AI-graded · Core Services - AuthKit +1
Why this grade
  1. RULES · SEV 1
    Sev 1 because Core Services - AuthKit had a partial outage
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Email delivery was delayed for AuthKit customers for about 15 minutes; the text does not say how many were hit.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 12:06 UTC · investigating
    We're seeing delays in email delivery. Our team is investigating. We will share an update as soon as possible.
  2. 12:18 UTC · identified
    We've identified the issue causing email delays. We are working to mitigate the issue.
  3. 12:21 UTC · resolved
    We've resolved the issue with email delivery delays.
Source
Jul 16, 20262h 18mSEV 1
Elevated Platform ErrorsWorkOS saw elevated error rates and latencies across its platform from about 8:00 to 10:10 UTC on July 16, 2026, affecting SSO, Directory Sync, Audit Logs, AuthKit, the dashboard and the admin portal. The provider identified a cause, deployed a fix, and resolved the incident. A postmortem was published later.AI-graded · Core Services - SSO +5
Why this grade
  1. RULES · SEV 1
    Sev 1 because Core Services - SSO had a major outage
  2. CLAUDE · SEV 1 · GLOBAL · MEDIUM CONFIDENCE
    Elevated error rates and latencies hit SSO, AuthKit, Directory Sync and Audit Logs across the platform for about two hours; dashboard and admin portal also affected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
7 updates
  1. 08:26 UTC · investigating
    We are seeing elevated error rates across our platform. Our team is investigating. We will share an update as soon as possible.
  2. 09:25 UTC · investigating
    We continue to investigate elevated error rates across our platform. We will share an update as soon as possible.
  3. 09:58 UTC · investigating
    We continue to investigate elevated error rates across our platform.
  4. 10:11 UTC · identified
    We've identified the cause of the elevated platform errors. We've implemented a fix and are seeing error rates decrease.
  5. 10:30 UTC · monitoring
    We have deployed the fix and we are now monitoring our systems to ensure the issue is resolved.
  6. 10:44 UTC · resolved
    This incident is resolved. We experienced elevated error rates and latencies between 8am and 10:10am UTC. We will deliver a full postmortem as soon as possible.
  7. 23:51 UTC · postmortem
    We’ve published a [post-mortem on the July 16 service disruption](https://workos.com/blog/service-disruption-on-july-16-2026) to our blog, detailing what happened and how we’re strengthening the resiliency of WorkOS products.
PostmortemSource
Jul 10, 20261h 11mSEV 2
Elevated error rates for standalone MFA requestsStandalone MFA API requests saw intermittent elevated errors for about 2 hours; AuthKit MFA was unaffected.AI-graded · one model or feature
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · SINGLE · MEDIUM CONFIDENCE
    Standalone MFA API requests saw intermittent elevated errors for about 2 hours; AuthKit MFA was unaffected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
  1. 19:26 UTC · monitoring
    Beginning at at 16:00 UTC, users of our standalone MFA API experienced intermittent elevated error rates for approximately 2 hours. MFA through AuthKit was not affected. This issue has been resolved, and we are continuing to monitor.
  2. 20:36 UTC · resolved
    We have restored full service to the standalone MFA API endpoints.
Source
Jun 22, 20262d 7hSEV 2 · SECURITY
Degraded performance for Directory Provisioning for AuthkitA data migration unintentionally disabled AuthKit directory provisioning for existing customer directories from June 22 to June 25. User creations, attribute and role updates, and deactivations were delayed or missed. Affected directories were restored and missed changes backfilled. Some removed users may have kept organization access; no misuse was found. No directory events were lost.AI-graded · some customers · Core Services - Directory Sync +1
Why this grade
  1. RULES · SEV 1
    Sev 1 because Core Services - Directory Sync had a partial outage
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE · SECURITY · BACK AFTER 2D 2H
    Directory provisioning into AuthKit stopped for affected customers for about three days; some deactivations were delayed, leaving residual access.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
7 updates
  1. 21:36 UTC · investigating
    We are seeing a delay in Directory Provisioning for Authkit, for any directories created before June 22, 21:36:17 UTC. Any directories created after this time are working as expected.
  2. 16:47 UTC · identified
    The underlying issue that has lead to a delay in provisioning has been identified, and a fix is being prepared
  3. 17:37 UTC · identified
    We have corrected the affected directories, and they are back to a provisioning status.
  4. 00:09 UTC · monitoring
    Provisioning has caught up for user creation, and new directory activity is syncing normally. We are still working through and monitoring the remaining synchronization catch-up, which is not yet fully complete. Another update to follow.
  5. 03:29 UTC · monitoring
    Synchronization has continued to catch up. We are continuing to monitor the few out of sync changes that are remaining.
  6. 05:12 UTC · resolved
    The remaining out-of-sync user records are now back in sync.
  7. 16:12 UTC · postmortem
    ## **Summary** Between June 22, 2026 at 21:36 UTC and June 25, 2026 at 05:12 UTC, Directory Provisioning for AuthKit was interrupted. During this period, directory updates continued to be received and processed by WorkOS, but downstream AuthKit user and organization membership changes were not applied as expected. The issue was caused by an internal data migration being run in production with parameters that unintentionally changed the AuthKit provisioning state for existing customer directories. Once identified, we restored the affected directory provisioning state, backfilled missed user provisioning updates, and deactivated memberships that had not been deactivated during the incident window. No directory events were lost or dropped during this period; however, events received during the incident period were not immediately propagated to AuthKit. Directories created after the migration were unaffected. ## Background Directory Provisioning for AuthKit works in two steps: WorkOS receives directory events from a customer's identity provider, then propagates those events downstream to create or update AuthKit users and organization memberships. That second step only happens if the directory is marked as eligible for downstream provisioning. If that eligibility is disabled, WorkOS continues receiving directory events normally, but the corresponding AuthKit updates are not applied. ## What Happened On June 22, 2026 at 21:36 UTC, an internal data migration was executed through an administrative migration tool. The migration changed the provisioning status for customer directories in a way that unintentionally disabled Directory Provisioning in AuthKit for affected customers. As a result: * New directory users created during the incident window were not consistently provisioned into AuthKit. * Some directory user updates, including attributes and roles, were not propagated to corresponding organization memberships. * Some users who were removed or deactivated in the directory were not fully deactivated in AuthKit during the incident period. This meant that, for the duration of the incident, some users who should have lost access to an organization may have retained it. Based on our review, we found no evidence that this residual access was exercised or misused during the incident window. The incident was reported on June 24, 2026 after customer reports of provisioning failures, approximately 42 hours after the migration ran. We did not have sufficient monitoring in place at the time that was sensitive enough to detect an abnormal drop in volume for Directory Provisioning in AuthKit, which is why detection relied on customer reports rather than internal alerting. Our team investigated the behavior, identified the migration as the cause, and immediately worked to restore affected directory provisioning state. We then performed additional remediation to address downstream effects from the incident window. This included provisioning missed users, refreshing affected membership attributes and roles, and deactivating stale memberships that should no longer have been active. ## Customer Impact & Recommended Actions Customers with Directory Provisioning enabled for AuthKit during the incident window may have experienced delayed user provisioning, attribute/role updates, or deactivation between June 22, 2026 21:36 UTC and June 25, 2026 05:12 UTC. All known gaps from this window have since been backfilled as part of our remediation. If you have reason to believe your AuthKit users or organization memberships were affected in a way not addressed by this remediation, please reach out to our support team so we can investigate your specific environment. ## **Timeline** * **June 22, 2026 21:36 UTC** – An internal data migration unintentionally disabled Directory Provisioning for affected directories. * **June 24, 2026 15:49 UTC** – The incident was reported after customer provisioning failures were identified. * **June 24, 2026 17:23 UTC** – We restored provisioning status for all affected directories, allowing new provisioning activity to resume. * **June 24, 2026 23:30 UTC** – We completed the first remediation pass to propagate provisioning updates missed during the incident period. * **June 25, 2026 02:10 UTC** – We completed remediation to refresh affected role and custom attribute data. * **June 25, 2026 05:12 UTC** – We completed deactivation remediation and considered the incident fixed. ## **Remediation** ### **Immediate Fixes** We took the following steps to restore service and correct affected data: * Restored the provisioning status for affected directories to resume Directory Provisioning in AuthKit. * Backfilled user creations, updates, and deactivations made by the identity provider during the incident window that had not been propagated to AuthKit users and organization memberships. * Removed the unsafe migration path that caused the incident so it could not be run again. ### **Near-Term Improvements** Additionally, we are making the following changes to reduce the likelihood and impact of similar incidents: * **Improved monitoring and detection:** We are adding additional monitoring and alerting for Directory Provisioning in AuthKit behavior, so we can more quickly respond if a similar issue were to occur in the future. * **Harden internal migration tooling:** We are reviewing access and safeguards for internal migration tools, including stronger controls for destructive operations and clearer scoping requirements. ## **Conclusion** Reliable user provisioning and deactivation are critical parts of identity infrastructure, and this incident did not meet the standard we hold ourselves to. We regret the impact this had on affected customers and their users. The incident has been resolved, affected data has been remediated, and we are implementing the controls and monitoring described above to help prevent similar incidents in the future. Please reach out to our team if you have additional questions on the impact to your environments.
PostmortemSource
Jun 22, 20263h 58mSEV 2
Elevated API ErrorsElevated API error rates for users routed through the Chicago (ORD) edge node for about 50 minutes; other locations were not reported affected.AI-graded · one location
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · LOCAL · MEDIUM CONFIDENCE · BACK AFTER 39M
    Elevated API error rates for users routed through the Chicago (ORD) edge node for about 50 minutes; other locations were not reported affected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 14:03 UTC · investigating
    We are investigating elevated error rates across our API. We apologize for the inconvenience and will share an update once we have more information.
  2. 14:42 UTC · monitoring
    We detected elevated errors from our Chicago (ORD) edge node. Errors have since recovered and we're continuing to monitor.
  3. 18:01 UTC · resolved
    From 13:35 UTC to 14:24 UTC users connecting through our Chicago (ORD) edge node may have experienced elevated API error rates. We have resolved the issue and are monitoring.
Source
Jun 9, 20260mSEV 2
SSO Request LatencySSO endpoints had elevated latency and intermittent timeouts for about 19 minutes; the text does not say how many customers were hit.AI-graded
Why this grade
  1. RULES · SEV 2
    Sev 2 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    SSO endpoints had elevated latency and intermittent timeouts for about 19 minutes; the text does not say how many customers were hit.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
1 update
  1. 09:00 UTC · resolved
    From 9:43 to 10:02 UTC SSO endpoints experienced increased latency and intermittent timeouts. We have resolved the issue and are monitoring.
Source
Jun 4, 20261h 27mSEV 2
Email delivery delaysEmails for AuthKit customers without custom domains were delayed because of an upstream email provider issue. The provider scaled up to clear the backlog. Delays ran from 2:50pm to 5:18pm PT, and the backlog was sent by the resolution.AI-graded · some customers · Core Services - AuthKit
Why this grade
  1. RULES · SEV 1
    Sev 1 because Core Services - AuthKit had a partial outage
  2. CLAUDE · SEV 2 · SUBSET · HIGH CONFIDENCE · BACK AFTER 1H 12M
    Email delivery was delayed for WorkOS AuthKit customers without custom domains for about two and a half hours; other customers were unaffected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
  1. 23:22 UTC · identified
    Email delivery for customers without custom domains is delayed due to an issue with our upstream service provider.
  2. 00:08 UTC · identified
    Our email provider is continuing to work through the backlog and has scaled up to speed up the process.
  3. 00:34 UTC · monitoring
    Email delivery has recovered. We're continuing to monitor.
  4. 00:49 UTC · resolved
    The backlog of messages have been sent and system performance has returned to its expected state. Sending delays occurred between 2:50pm – 5:18pm PT.
Source
May 29, 202616mSEV 2
Elevated Events API ErrorsEvents API GET /events requests errored for about 16 minutes; the text does not say how many customers were hit.AI-graded · Core Services - Directory Sync
Why this grade
  1. RULES · SEV 2
    Sev 2 because Core Services - Directory Sync had degraded performance
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 16M
    Events API GET /events requests errored for about 16 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. 02:30 UTC · identified
    We have identified the cause of the elevated errors affecting the GET /events API and are working on a resolution. We’ll share another update soon.
  2. 02:46 UTC · resolved
    The issue affecting the Events API GET /events endpoint has been resolved. The fix has been deployed, and affected requests are now processing normally.
Source
May 22, 202629mSEV 3
Dashboard and Docs unavailableCSS assets for the WorkOS Dashboard, Admin Portal, Docs and hosted result pages failed to load, leaving them unstyled and hard to use. Underlying APIs, authentication and data were not affected. A fix was deployed and the incident was resolved about 30 minutes after it started.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 · GLOBAL · HIGH CONFIDENCE
    Dashboard CSS failed to load so the WorkOS Dashboard was unstyled and hard to use for about 30 minutes; APIs and auth were unaffected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
  1. 18:29 UTC · investigating
    We are investigating an issue with our Dashboard. We will share an update as soon as possible.
  2. 18:32 UTC · investigating
    We're aware of a styling issue currently affecting the WorkOS Dashboard. CSS assets are failing to load, leaving the Dashboard in an unstyled and difficult-to-use state. Underlying APIs, authentication, and data are not impacted - this is limited to the Dashboard UI. We're investigating and will update shortly.
  3. 18:55 UTC · monitoring
    A fix has been deployed for the issue affecting static asset loading on the WorkOS Dashboard, Admin Portal, Docs, and hosted result pages. We are continuing to monitor for full recovery.
  4. 18:58 UTC · resolved
    This incident has been resolved.
Source
May 19, 202617mSEV 2
Webhook delivery delaysDelivery of a subset of webhooks to customer apps was delayed for about 17 minutes until the queued backlog cleared.AI-graded · some customers
Why this grade
  1. RULES · SEV 1
    Sev 1 from the incident title (no components listed)
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    Delivery of a subset of webhooks to customer apps was delayed for about 17 minutes until the queued backlog cleared.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
  1. 21:43 UTC · identified
    We are experiencing delays delivering a subset of webhooks. We have identified the issue and working on a remediation.
  2. 22:00 UTC · resolved
    The webhooks queue backlog has been delivered. Thank you for your patience.
Source
May 14, 20262mSEV 2
OIDC ErrorsOIDC connections errored briefly for SSO customers; the text gives no count or region and it was resolved in under two minutes.AI-graded · Core Services - SSO
Why this grade
  1. RULES · SEV 2
    Sev 2 because Core Services - SSO had degraded performance
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    OIDC connections errored briefly for SSO customers; the text gives no count or region and it was resolved in under two minutes.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
  1. 15:10 UTC · monitoring
    We experienced errors in our OIDC connections. The issue is now resolved.
  2. 15:12 UTC · resolved
    This issue is now resolved.
Source
May 12, 20261h 15mSEV 2
Emails being delivered with empty copySome AuthKit emails, such as invitations, were delivered with empty copy in some email clients, including Gmail. WorkOS identified the issue and applied a fix. Newly sent emails were displaying properly again by 20:29 UTC.AI-graded · some customers · Core Services - AuthKit
Why this grade
  1. RULES · SEV 1
    Sev 1 because Core Services - AuthKit had a partial outage
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE · BACK AFTER 1H 15M
    Some AuthKit emails such as invitations arrived with empty copy in some email clients, mainly Gmail, for about an hour.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
  1. 19:14 UTC · investigating
    We are investigating reports of some AuthKit emails, such as invitations, being delivered with empty copy.
  2. 19:37 UTC · investigating
    We are investigating reports of AuthKit emails rendering with no copy in some email clients.
  3. 19:43 UTC · identified
    We've identified the issue and are applying a fix.
  4. 20:29 UTC · resolved
    Newly-sent emails from WorkOS are now displaying properly in Gmail again.
Source
May 5–12, 20267d 1hSEV 2
Webhook delivery delayed2 incidents
  1. Tue, May 5 16:45 UTC3h 03mSEV 2
    Webhook delivery delayedAuthkit webhook deliveries to customer apps were delayed for about three hours; the full extent was not described.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
      Authkit webhook deliveries to customer apps were delayed for about three hours; the full extent was not described.
    3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
    3 updates
    1. 16:45 UTC · identified
      We are investigating a delay in sending Authkit webhooks. We will share an update once we have more information.
    2. 18:51 UTC · monitoring
      Webhook delivery for Authkit is delayed but recovering. We are monitoring the situation.
    3. 19:48 UTC · resolved
      We have recovered from any delays delivering webhooks.
    Source
  2. Tue, May 12 17:59 UTC41mSEV 2
    Elevated Webhook LatencyWorkOS webhook deliveries were delayed starting 17:59 UTC on May 12, 2026. The team identified the issue, applied mitigations, and saw delivery recover. The incident was resolved at 18:41 UTC. No specific cause was given.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 22M
      Webhook deliveries to customers' apps were delayed for about 40 minutes; 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. 17:59 UTC · investigating
      We are seeing delays delivering webhooks. Our team is currently investigating.
    2. 18:04 UTC · identified
      Our team has identified the issue and is implementing mitigations.
    3. 18:21 UTC · monitoring
      Our team is seeing webhook delivery recover and we are continuing to monitor the situation.
    4. 18:41 UTC · resolved
      This has been resolved.
    Source
May 9, 202610mSEV 3
Dashboard login errorsDashboard logins returned 504 errors for about 10 minutes; the API and AuthKit were unaffected.AI-graded
Why this grade
  1. RULES · SEV 3
    Sev 3 from the incident title (no components listed)
  2. CLAUDE · SEV 3 · UNCLEAR · MEDIUM CONFIDENCE
    Dashboard logins returned 504 errors for about 10 minutes; the API and AuthKit were unaffected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
  1. 00:35 UTC · identified
    We are investigating reports of 504 Gateway Timeout errors affecting logins to the WorkOS Dashboard. Users may be unable to sign in at dashboard.workos.com via SSO or Google sign-in. The WorkOS API and AuthKit are unaffected. We will share another update shortly.
  2. 00:45 UTC · resolved
    This incident has been resolved.
Source
May 1, 20260mSEV 4
Elevated Dashboard ErrorsWorkOS Dashboard showed elevated errors for a short period; the text does not say how many users were affected.AI-graded · Supporting Services - Dashboard
Why this grade
  1. RULES · SEV 4
    Sev 4 because Supporting Services - Dashboard had degraded performance
  2. CLAUDE · SEV 4 · UNCLEAR · MEDIUM CONFIDENCE
    WorkOS Dashboard showed elevated errors for a short period; the text does not say how many users were affected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 20:28 UTC · investigating
    We are investigating an issue with our Dashboard. We will share an update as soon as possible.
  2. 20:40 UTC · monitoring
    We've identified and addressed the issue. We'll continue to monitor.
  3. 20:51 UTC · resolved
    The issue has been resolved. The WorkOS Dashboard is fully operational.
Source
Apr 30, 20261h 24mSEV 2
Email Delivery DelaysAuthKit emails, such as sign-in and verification messages, were delivered late for some users starting at 01:00 UTC on April 30, 2026. The team mitigated the issue, monitoring showed delivery returning to normal at 01:56 UTC, and the incident was resolved at 02:23 UTC.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 56M
    Email delivery delays hit some AuthKit users for about an hour and a half; the rest were unaffected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
4 updates
  1. 01:00 UTC · investigating
    We’re seeing email delivery delays affecting some users. Our team is investigating.
  2. 01:30 UTC · identified
    Our team has identified the issue and is actively working on mitigations to restore email delivery for the affected subset of users.
  3. 01:56 UTC · monitoring
    Email delivery is returning to normal. Our team is continuing to monitor.
  4. 02:23 UTC · resolved
    This has been resolved.
Source
Apr 20, 20261mSEV 2
SSO API Latency Degradation Caused by Transient Capacity ConstraintsSSO endpoints had increased latency and intermittent timeouts for about 13 minutes; the text does not say how many customers were hit.AI-graded · 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 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 1M
    SSO endpoints had increased latency and intermittent timeouts for about 13 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. 19:16 UTC · identified
    Between 14:40 and 14:53 UTC, SSO endpoints experienced increased latency and intermittent timeouts. The issue was caused by a temporary reduction in available capacity due to an underlying infrastructure event, which led to a brief period of degraded performance
  2. 19:17 UTC · resolved
    The issue has been resolved, and SSO login performance has returned to normal. We will continue to monitor closely to ensure stability.
Source
Apr 16, 20262h 17mSEV 2
Increased 429 Errors on /directory_users endpointElevated HTTP 429 (Too Many Requests) responses hit the /directory_users endpoint in Directory Sync starting 20:54 UTC on April 16, 2026. A fix was deployed and error rates returned to normal by 23:10 UTC. The text does not describe the cause or how many customers were affected.AI-graded · some customers · Core Services - Directory Sync
Why this grade
  1. RULES · SEV 2
    Sev 2 because Core Services - Directory Sync had degraded performance
  2. CLAUDE · SEV 2 · SUBSET · MEDIUM CONFIDENCE
    The /directory_users endpoint returned elevated HTTP 429 rate-limit errors for about two hours; the text does not say how many customers were hit.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 20:54 UTC · investigating
    We’re currently investigating an elevated rate of HTTP 429 (Too Many Requests) responses impacting the /directory_users endpoint. Mitigations are in progress, and we’ll provide an update shortly.
  2. 20:59 UTC · monitoring
    We’ve deployed a fix and are seeing early signs of recovery, with 429 error rates beginning to decline. We’re continuing to monitor closely to ensure the endpoint fully stabilizes and will provide further updates as needed.
  3. 23:10 UTC · resolved
    The issue has been resolved. 429 error rates have returned to normal levels for the affected endpoint.
Source
Mar 27, 20261h 19mSEV 4
Elevated Dashboard ErrorsDashboard custom CSS branding editor and JWT template editor were unavailable for about six minutes; other dashboard functions were not described as affected.AI-graded · some customers · Supporting Services - Dashboard
Why this grade
  1. RULES · SEV 4
    Sev 4 because Supporting Services - Dashboard had degraded performance
  2. CLAUDE · SEV 4 · SUBSET · HIGH CONFIDENCE · BACK AFTER 6M
    Dashboard custom CSS branding editor and JWT template editor were unavailable for about six minutes; other dashboard functions were not described as affected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 21:57 UTC · investigating
    We are investigating an issue with our Dashboard. The custom branding editor's custom CSS code editor and the JWT editor are currently not available. We will share an update as soon as possible.
  2. 22:03 UTC · monitoring
    The custom branding code editor and JWT template editor functionality has been restored.
  3. 23:15 UTC · resolved
    We think the impact from the issue is over.
Source
Mar 17, 202618mSEV 2
Elevated API ErrorsElevated API errors and latency hit SSO and AuthKit for about 18 minutes; the text does not say how many customers were affected.AI-graded · 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 · UNCLEAR · MEDIUM CONFIDENCE · BACK AFTER 15M
    Elevated API errors and latency hit SSO and AuthKit for about 18 minutes; the text does not say how many customers were affected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
3 updates
  1. 14:12 UTC · investigating
    We’re investigating elevated API errors and latency.
  2. 14:27 UTC · monitoring
    Services have returned to normal operation
  3. 14:30 UTC · resolved
    This incident has been resolved.
Source
Feb 24, 20261h 06mSEV 2
Elevated API ErrorsAuthKit API requests saw elevated errors and latency for about an hour; the text does not say how many customers were hit.AI-graded · Core Services - AuthKit
Why this grade
  1. RULES · SEV 1
    Sev 1 because Core Services - AuthKit had a partial outage
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    AuthKit API requests saw elevated errors and latency 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
3 updates
  1. 10:11 UTC · investigating
    We’re investigating elevated API errors and latency.
  2. 10:39 UTC · identified
    Our team has identified the issue and is implementing a fix.
  3. 11:16 UTC · resolved
    All services have returned to normal. This incident is resolved.
Source
Jan 27, 202645mSEV 2
Elevated Error RatesWorkOS saw elevated error rates and latencies across SSO, Directory Sync and AuthKit starting 18:57 UTC on January 27, 2026. An upstream provider caused the problem and was fixing it. Error rates returned to normal by 19:35 UTC and the incident was resolved at 19:42 UTC.AI-graded · Core Services - SSO +2
Why this grade
  1. RULES · SEV 1
    Sev 1 because Core Services - SSO had a partial outage
  2. CLAUDE · SEV 2 · UNCLEAR · MEDIUM CONFIDENCE
    Elevated error rates and latency hit SSO, Directory Sync and AuthKit for about 45 minutes; 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:57 UTC · investigating
    We are seeing elevated error rates across our services. We will share an update as soon as possible.
  2. 19:11 UTC · monitoring
    Our upstream provider has identified the problem and working on a fix. We continue to monitor.
  3. 19:35 UTC · monitoring
    Error rates and latencies returned to normal at 11:02am PT, but we are continuing to monitor until the upstream provider resolves the incident on their side.
  4. 19:42 UTC · resolved
    This incident has been resolved.
Source
Jan 22, 202615h 32mSEV 2
Degraded Email Delivery to Microsoft Outlook InboxesOutbound auth emails to Outlook and Microsoft 365 inboxes were delayed or not delivered for about 15 hours; other providers were unaffected.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
    Outbound auth emails to Outlook and Microsoft 365 inboxes were delayed or not delivered for about 15 hours; other providers were unaffected.
  3. Claude Haiku 5.5 · prompt v11 · Oct 24, 2026 · Raw record
2 updates
  1. 23:44 UTC · monitoring
    We are experiencing degraded delivery of outbound emails from WorkOS to Outlook and Microsoft 365 inboxes. Some messages may be delayed or not delivered. Delivery to non-Outlook providers is unaffected. We are monitoring the situation and will share updates as they become available.
  2. 15:16 UTC · resolved
    The issue impacting outbound email delivery to Outlook and Microsoft 365 inboxes has been resolved. Delivery is now operating normally across all providers.
Source

Peers, 90 days

Compare
MailerSendGrade A+100.00% up0 incidentsMTTR –MapboxGrade A+99.99% up2 incidentsMTTR 12h 38mPaddleGrade A+100.00% up3 incidentsMTTR 47mLoopsGrade A+100.00% up1 incidentMTTR 1h 34mKindeGrade A+99.99% up2 incidentsMTTR 1h 12mCloudinaryGrade A99.97% up5 incidentsMTTR 1h 47mAblyGrade A99.98% up7 incidentsMTTR 7mMailgunGrade A99.96% up9 incidentsMTTR 42mPusherGrade A99.97% up2 incidentsMTTR 3h 45mInngestGrade B99.63% up14 incidentsMTTR 43mClerkGrade C99.91% up10 incidentsMTTR 3h 26mResendGrade C99.85% up25 incidentsMTTR 24mStytchGrade C99.83% up6 incidentsMTTR 2h 29mWorkOSGrade C99.42% up21 incidentsMTTR 1h 05mTwilioGrade D99.10% up60 incidentsMTTR 6h 43mPlaidGrade D98.13% up18 incidentsMTTR 3h 38m

README badge

WorkOS's live grade, for your README.

WorkOS grade badge
[![workos on downagain.dev](https://downagain.dev/badge/workos.svg)](https://downagain.dev/p/workos)