WorkOS Outage History

Started Oct 29, 2026, 05:34 PM UTC· resolved Oct 29, 2026, 07:52 PM UTC

1. investigating Oct 29, 2026, 05:34 PM UTC

   We are investigating timeouts on the /sso/profile endpoint. We apologize for the inconvenience and will share an update once we have more information.

2. identified Oct 29, 2026, 05:54 PM UTC

   We've identified the issue causing the SSO profile API timeouts and are working on a fix.

3. monitoring Oct 29, 2026, 06:13 PM UTC

   We’ve resolved the issue causing timeouts on the SSO profile API and are monitoring.

4. resolved Oct 29, 2026, 07:52 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 23, 2026, 03:57 PM UTC· resolved Oct 23, 2026, 05:01 PM UTC

1. investigating Oct 23, 2026, 03:57 PM UTC

   We are seeing elevated errors and request latency across SSO and AuthKit due to network degradation and an upstream provider.

2. monitoring Oct 23, 2026, 04:09 PM UTC

   We're seeing recovery across services and will continue to monitor.

3. resolved Oct 23, 2026, 05:01 PM UTC

   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.

Read the full incident report →

Started Oct 19, 2026, 07:23 PM UTC· resolved Oct 19, 2026, 08:21 PM UTC

1. investigating Oct 19, 2026, 07:23 PM UTC

   We are investigating elevated error rates from 19:09 to 19:16 UTC.

2. identified Oct 19, 2026, 07:27 PM UTC

   The issue has been identified and a fix is being implemented.

3. identified Oct 19, 2026, 07:27 PM UTC

   We are continuing to work on a fix for this issue.

4. resolved Oct 19, 2026, 08:21 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 15, 2026, 05:17 PM UTC· resolved Oct 15, 2026, 09:51 PM UTC

1. investigating Oct 15, 2026, 05:17 PM UTC

   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. monitoring Oct 15, 2026, 05:55 PM UTC

   We are seeing some recovery after our upstream provider has enabled alternate delivery routes. We are continuing to monitor.

3. resolved Oct 15, 2026, 09:51 PM UTC

   We've resolved the issue with Radar SMS challenge verifications to China.

Read the full incident report →

Started Oct 09, 2026, 08:20 PM UTC· resolved Oct 09, 2026, 08:21 PM UTC

1. resolved Oct 09, 2026, 07:30 PM UTC

   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.

Read the full incident report →

Started Oct 01, 2026, 09:16 PM UTC· resolved Oct 01, 2026, 09:58 PM UTC

1. investigating Oct 01, 2026, 09:16 PM UTC

   We are currently investigating this issue.

2. monitoring Oct 01, 2026, 09:20 PM UTC

   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. resolved Oct 01, 2026, 09:58 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Oct 01, 2026, 03:34 PM UTC· resolved Oct 01, 2026, 03:40 PM UTC

1. resolved Oct 01, 2026, 03:30 PM UTC

   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.

Read the full incident report →

Started Sep 18, 2026, 10:49 PM UTC· resolved Sep 18, 2026, 11:29 PM UTC

1. investigating Sep 18, 2026, 10:49 PM UTC

   We are investigating an issue with our API. We apologize for the inconvenience and will share an update once we have more information.

2. investigating Sep 18, 2026, 11:01 PM UTC

   We're continuing to investigate this issue to identify the root cause. We'll share another update soon.

3. identified Sep 18, 2026, 11:05 PM UTC

   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. monitoring Sep 18, 2026, 11:09 PM UTC

   Our initial remediations are in place, and services have recovered. We're continuing to monitor closely.

5. resolved Sep 18, 2026, 11:29 PM UTC

   Our remediations continue to be effective, and services continue to be recovered. We will continue further investigation and additional preventative measures.

6. postmortem Sep 19, 2026, 01:19 AM UTC

   On September 18, between 22:40–23:03 UTC, WorkOS experienced a partial outage affecting authentication and other API requests. A failover of the cache used for feature flag evaluation left app connections stalled, and requests waiting on flag checks held database connections open, causing queues to build and other requests to fail. Many of you experienced failures, including failed sign-ins and long delays. We're sorry for the disruption this caused. We're taking this event seriously and have already fixed the root cause, with work underway on additional layers of protection. We will publish a full RCA next week explaining in detail what failed, why recovery was not automatic \(should have been ~seconds\), and what we're changing to prevent this issue from happening again.

7. postmortem Sep 22, 2026, 12:53 AM UTC

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

Read the full incident report →

Started Sep 14, 2026, 07:08 PM UTC· resolved Sep 14, 2026, 08:00 PM UTC

1. investigating Sep 14, 2026, 07:08 PM UTC

   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. monitoring Sep 14, 2026, 07:16 PM UTC

   We've fixed an issue affecting Admin Portal links for customers without custom domains and are monitoring.

3. resolved Sep 14, 2026, 08:00 PM UTC

   We've resolved an issue loading Admin Portal links for customers without custom domains. If you're still experiencing issues please contact support.

Read the full incident report →

Started Sep 09, 2026, 09:00 PM UTC· resolved Sep 09, 2026, 11:02 PM UTC

1. investigating Sep 09, 2026, 09:00 PM UTC

   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. resolved Sep 09, 2026, 11:02 PM UTC

   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. postmortem Sep 16, 2026, 09:10 PM UTC

   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])\).

Read the full incident report →

Started Sep 02, 2026, 04:39 PM UTC· resolved Sep 02, 2026, 07:06 PM UTC

1. identified Sep 02, 2026, 04:39 PM UTC

   We have identified increased failures delivering static assets to end users with strict network allowlists. A fix is in progress.

2. monitoring Sep 02, 2026, 06:33 PM UTC

   We have mitigated the issue and are continuing to monitor.

3. resolved Sep 02, 2026, 07:06 PM UTC

   Static assets delivery rates have recovered.

Read the full incident report →

Started Aug 31, 2026, 02:10 PM UTC· resolved Aug 31, 2026, 02:45 PM UTC

1. investigating Aug 31, 2026, 02:10 PM UTC

   We are investigating an issue with successful delivery of emails.

2. resolved Aug 31, 2026, 02:45 PM UTC

   This degradation in delivery was limited to upstream testing infrastructure which has since recovered. There was no external impact.

Read the full incident report →

Started Aug 27, 2026, 01:48 PM UTC· resolved Aug 27, 2026, 02:04 PM UTC

1. monitoring Aug 27, 2026, 01:48 PM UTC

   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. resolved Aug 27, 2026, 02:04 PM UTC

   The mitigation is in place and errors rates have returned to normal. We will continue to monitor.

Read the full incident report →

Started Aug 25, 2026, 05:35 PM UTC· resolved Aug 25, 2026, 06:41 PM UTC

1. investigating Aug 25, 2026, 05:35 PM UTC

   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. identified Aug 25, 2026, 05:41 PM UTC

   We have applied a fix and are monitoring the system to verify that Dashboard sign-in is recovering.

3. monitoring Aug 25, 2026, 05:54 PM UTC

   We have confirmed our fix resolved the elevated errors affecting sign-in to the WorkOS Dashboard and are continuing to monitor.

4. resolved Aug 25, 2026, 06:41 PM UTC

   This incident is resolved.

Read the full incident report →

Started Aug 18, 2026, 11:59 PM UTC· resolved Aug 19, 2026, 03:53 AM UTC

1. resolved Aug 19, 2026, 12:00 AM UTC

   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.

Read the full incident report →

Started Aug 15, 2026, 12:24 AM UTC· resolved Aug 16, 2026, 10:04 PM UTC

1. investigating Aug 15, 2026, 12:24 AM UTC

   We are seeing deliverability issues with emails sent to Microsoft / Outlook recipients.

2. identified Aug 15, 2026, 01:35 AM UTC

   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. monitoring Aug 15, 2026, 03:32 AM UTC

   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. identified Aug 15, 2026, 04:21 PM UTC

   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. resolved Aug 16, 2026, 10:04 PM UTC

   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.

Read the full incident report →

Started Aug 14, 2026, 08:14 PM UTC· resolved Aug 14, 2026, 08:45 PM UTC

1. investigating Aug 14, 2026, 08:14 PM UTC

   We're investigating delays in email deliverability.

2. monitoring Aug 14, 2026, 08:44 PM UTC

   We've mitigated the impact and email delivery is returning to normal.

3. resolved Aug 14, 2026, 08:45 PM UTC

   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.

Read the full incident report →

Started Aug 11, 2026, 06:02 PM UTC· resolved Aug 11, 2026, 07:24 PM UTC

1. investigating Aug 11, 2026, 06:02 PM UTC

   We are investigating intermittent sign-in failures on the WorkOS Dashboard. We will share an update as soon as possible.

2. resolved Aug 11, 2026, 07:24 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Aug 05, 2026, 06:04 PM UTC· resolved Aug 05, 2026, 06:28 PM UTC

1. investigating Aug 05, 2026, 06:04 PM UTC

   We are investigating an issue with our webhooks. We apologize for the inconvenience and will share an update once we have more information.

2. resolved Aug 05, 2026, 06:28 PM UTC

   This was an issue with our internal telemetry - there is no customer impact. Sorry for the false alarm.

Read the full incident report →

Started Jul 31, 2026, 04:01 PM UTC· resolved Jul 31, 2026, 06:06 PM UTC

1. investigating Jul 31, 2026, 04:01 PM UTC

   We're investigating an increase in Single Sign-On errors. We will share an update as soon as possible.

2. investigating Jul 31, 2026, 04:12 PM UTC

   It appears some users may be experiencing a redirect loop during sign-on, we are narrowing in on a cause

3. investigating Jul 31, 2026, 04:16 PM UTC

   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. investigating Jul 31, 2026, 04:34 PM UTC

   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. investigating Jul 31, 2026, 05:00 PM UTC

   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. monitoring Jul 31, 2026, 05:10 PM UTC

   The fix has deployed, we are monitoring systems to verify the impact is fully mitigated

7. resolved Jul 31, 2026, 06:06 PM UTC

   The issue has been resolved.

Read the full incident report →

Started Jul 29, 2026, 06:30 PM UTC· resolved Jul 29, 2026, 07:54 PM UTC

1. investigating Jul 29, 2026, 06:30 PM UTC

   We're investigating delays in email deliverability.

2. identified Jul 29, 2026, 06:36 PM UTC

   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. monitoring Jul 29, 2026, 07:24 PM UTC

   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. resolved Jul 29, 2026, 07:54 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 27, 2026, 07:09 PM UTC· resolved Jul 27, 2026, 09:12 PM UTC

1. investigating Jul 27, 2026, 07:09 PM UTC

   We're investigating delays in webhook delivery. We will share an update as soon as possible.

2. identified Jul 27, 2026, 07:36 PM UTC

   We have identified the cause of the delays in webhook delivery and are rolling out a fix to reduce processing latency.

3. identified Jul 27, 2026, 08:34 PM UTC

   We have rolled out a fix and are seeing improvements to webhook delivery times. We will provide another update soon.

4. monitoring Jul 27, 2026, 08:54 PM UTC

   We have confirmed that webhook delivery times are back to normal levels. We are continuing to monitor.

5. monitoring Jul 27, 2026, 09:11 PM UTC

   This has been resolved.

6. resolved Jul 27, 2026, 09:12 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 27, 2026, 02:10 PM UTC· resolved Jul 27, 2026, 05:37 PM UTC

1. investigating Jul 27, 2026, 02:10 PM UTC

   We are investigating reports that email delivery statuses in Dashboard are not being updated.

2. investigating Jul 27, 2026, 02:33 PM UTC

   We are continuing to investigate email delivery errors in addition to Dashboard email delivery statuses not being updated.

3. monitoring Jul 27, 2026, 03:36 PM UTC

   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. resolved Jul 27, 2026, 05:37 PM UTC

   Email delivery is operating normally.

Read the full incident report →

Started Jul 27, 2026, 10:05 AM UTC· resolved Jul 27, 2026, 01:04 PM UTC

1. investigating Jul 27, 2026, 10:05 AM UTC

   We are investigating elevated errors during delivery of emails.

2. monitoring Jul 27, 2026, 11:03 AM UTC

   We have implemented a mitigation and are continuing to monitor.

3. investigating Jul 27, 2026, 11:20 AM UTC

   Our mitigation did not fully resolve the issue. We are continuing to investigate.

4. monitoring Jul 27, 2026, 12:11 PM UTC

   We have applied a refined mitigation and are continuing to monitor delivery rates.

5. resolved Jul 27, 2026, 01:04 PM UTC

   Delivery rates have recovered.

Read the full incident report →

Started Jul 22, 2026, 01:35 AM UTC· resolved Jul 22, 2026, 02:51 AM UTC

1. investigating Jul 22, 2026, 01:35 AM UTC

   We're investigating possible email delivery delays.

2. identified Jul 22, 2026, 02:16 AM UTC

   We've identified the issue and are implementing remediations.

3. monitoring Jul 22, 2026, 02:19 AM UTC

   We've remediated the issue and are seeing email delivery recover.

4. resolved Jul 22, 2026, 02:51 AM UTC

   This has been resolved.

Read the full incident report →