outages.live
Live

WorkOS

WorkOS is operational

Checked 56 s ago Operational

History

90 days agoToday

Incidents in 90 days

17

Days with an incident

17

Median duration

58 min

Longest incident

44 h 29 min

Components

7

Supporting Services

Dashboard Operational
90 days ago4 days with an incidentToday
Admin Portal Operational
90 days ago1 day with an incidentToday

Core Services

AuthKit Operational
90 days ago9 days with an incidentToday
SSO Operational
90 days ago2 days with an incidentToday
Directory Sync Operational
90 days agoNo incidentsToday
Audit Logs Operational
90 days ago1 day with an incidentToday
FGA Operational
90 days agoNo incidentsToday

Past incidents

Provider status pageTimes in UTC

Oct 29, 2026

Duration2 h 18 min17:34 to 19:52SSO Profile API TimeoutsPartial outage

This incident has been resolved.

Oct 23, 2026

Duration1 h 3 min15:57 to 17:01Elevated errors across SSO and AuthKitPartial outage

This is now resolved. Errors and latency were elevated between 15:21 and 15:50 UTC primarily for requests served by MIA and ATL with some impact on the US east coast and northern South America.

Oct 19, 2026

Duration58 min19:23 to 20:21Elevated AuthKit Error RatesPartial outage

This incident has been resolved.

Oct 15, 2026

Duration4 h 34 min17:17 to 21:51Radar SMS challenge failures for phone numbers in mainland China (+86)Partial outage

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

Oct 1, 2026

Duration42 min21:16 to 21:58Elevated errors for Audit LogsDegraded

This incident has been resolved.

Duration1 min15:30 to 15:30Elevated API and AuthKit errors for some requests (Columbus, OH region)Degraded

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.

Sep 18, 2026

Duration40 min22:49 to 23:29Elevated API ErrorsPartial outage

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

Sep 14, 2026

Duration52 min19:08 to 20:00Elevated Admin Portal ErrorsPartial outage

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

Sep 9, 2026

Duration2 h 2 min21:00 to 23:02Form POST failures for some Authkit customersPartial outage

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

Sep 2, 2026

Duration2 h 27 min16:39 to 19:06Static asset delivery failuresPartial outage

Static assets delivery rates have recovered.

Aug 31, 2026

Duration35 min14:10 to 14:45Degraded outbound email deliveryDegraded

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

Aug 27, 2026

Duration16 min13:48 to 14:04Degraded Vault pages in DashboardNotice

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

Aug 25, 2026

Duration1 h 5 min17:35 to 18:41Dashboard sign-in errorsPartial outage

This incident is resolved.

Follow WorkOS

Your coding agent knows when WorkOS is down, and tells you when a failure is theirs, not yours. You can also get WorkOS incidents in a feed reader or in Slack.

Prompt
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.

Add it as a remote MCP server named "outages" at https://outages.live/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.

Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "workos" and tell me if WorkOS has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.

Paste this into any coding agent. It adds the server with its own MCP setup.

RSS
https://outages.live/feed.xml?providers=workos
Slack
/feed subscribe https://outages.live/feed.xml?providers=workos

Go from tracking outages to fixing production issues with Polylane.

Try Polylane