checked Oct 23, 2026 2:27 AM UTC · Okta's official status page
Okta is up and running.
All components operational
Statusfield watches Okta alongside the rest of your stack and tells you when its status changes. Email, Slack, Microsoft Teams, PagerDuty, and webhooks.
30-day free trial — no card needed. First-time customers; continued monitoring requires a paid subscription.
6 reports published by Okta in the last 30 days
When Okta breaks, it is typically resolved in 3h 4m — median across 4 resolved incidents over 30 days.
ResolvedOct 21 · 23:27 UTC
The issue affecting reporting services on EMEA Cell 9 has been addressed. The third-party provider has deployed a fix, and all system metrics have stabilized. Additional root cause information will be available within 5 business days.
Reported by Okta on their status page.
ResolvedOct 21 · 21:32 UTC
The issue causing Group Push failures has been resolved. Additional root cause information will be available within five business days.
Reported by Okta on their status page.
ResolvedOct 20 · 23:44 UTC
We sincerely apologize for any impact this incident has caused to you, your business, and your customers. At Okta, trust and transparency are our top priorities. Outlined below are the facts regarding this incident. We are committed to implementing improvements to the service to prevent future occurrences of this incident. Detection and Impact: On October 13th, 2026, at 5:57 AM PT, Okta customer reports alerted our engineering team of group push membership processing delays for EMEA Cell EU1. During this time, customers may have experienced delays in Group Push operations. Administrators discovered the issue only when downstream applications failed to reflect changes or when "Last Push" timestamps were updated without completing, ultimately delaying access to new membership changes in provisioned downstream applications. Root Cause Summary: The root cause was a previously deployed configuration change intended to reduce impact on datastore CPU. However, this change had the unintended side effect of ultimately delaying the update of group membership in downstream provisioned applications. Remediation Steps: At 6:57 AM PT, Engineering identified the root cause of the delay and promptly reverted the configuration change. To accelerate recovery and clear the resulting backlog, engineering temporarily increased processing capacity, allowing the backlog of group membership processing to return to nominal processing rates. These actions successfully addressed the issue, and normal operations were restored by 9:07 AM PT. Preventative Actions: In order to prevent similar incidents from happening again, Okta has implemented the following: Updated alerts for identification and faster notification of these scenarios Additionally, Okta is reviewing testing scenarios and monitoring these processes. Duration (# of minutes): 567
Reported by Okta on their status page.
ResolvedOct 20 · 19:19 UTC
We sincerely apologize for any impact this incident has caused to you, your business, and your customers. At Okta trust and transparency are our top priorities. Outlined below are the facts regarding this incident. We are committed to implementing improvements to the service to prevent future occurrences of this incident.
Detection and Impact: On October 10th at 12:50 AM PT, Okta’s monitoring systems alerted on-call teams to a database server issue on EMEA Cell EU1.
During this time, administrators and end users may have encountered Read Only Mode (See KB: https://support.okta.com/help/s/article/What-is-Oktas-Readonly-Mode ) during this period, as well as errors related to write operations and certain authentication flows.
Root Cause Summary: The root cause of the disruption was an unexpected crash of the primary data store supporting the impacted cell, which automatically resulted in Okta application servers transitioning to Read Only mode to ensure data integrity.
Remediation Steps: Immediately upon receiving alerts, incident response processes were activated. On-call incident responders analyzed the database service failure and took actions to failover to a healthy primary and restore service functionality.
Preventative Actions: In order to prevent and mitigate similar incidents in the future, Okta has currently implemented the following:
Additionally, Okta is reviewing operating procedures to recover the service faster and is currently working with external infrastructure vendors to investigate the underlying cause of the database crash.
Duration (# of minutes): 35
Reported by Okta on their status page.
ResolvedOct 9 · 03:44 UTC
We sincerely apologize for any impact this incident has caused to you, your business, and your customers. At Okta, trust and transparency are our top priorities. Outlined below are the facts regarding this incident. We are committed to implementing improvements to the service to prevent future occurrences of this incident. Detection and Impact: On October 1st, 2026, at 6:55 AM PDT, Okta customer reports alerted our team of workflow lag issues for US Cells OK6, OK7, OK8, OK9, and OK11, as well as Okta Preview Cell OP1. During this incident, customers using Okta event hooks experienced delays receiving subscribed events. Workflows triggered by Okta webhooks would have also executed with delays or become non-responsive. In US East Okta Cell 11, a subset of events was dropped entirely, and the webhook delivery failure logs do not appear in the system logs. Root Cause Summary: During our transition to a new internal event delivery system, Okta experienced an issue where retried, consistently failing event hooks deliveries blocked the processing of the queue. Once the primary queue reached max retry events, the system was unable to process additional messages from the queue, causing widespread delivery delays. Additionally, because the queue did not throw error alerts when it became saturated, our standard monitoring did not immediately flag the issue, allowing the backlog to persist until customers noticed gaps in their expected data. A small number of customers were affected by a migration misconfiguration stemming from an unrelated prior incident. This configuration error caused the new delivery system to skip processing a small portion of events entirely. Remediation Steps: Once the source of the issue was identified, Okta's engineering team immediately began rolling back to the original event delivery service at approximately 7:30 AM PT. The rollbacks were completed at approximately 1:21 PM PT. Any events triggered after 1:21 PM encountered no lag. The remaining events in the new system queue were organically processed by 4:45 PM PT. These actions successfully addressed the issue, and normal operations were restored by 4:45 PM PT. Preventative Actions: In order to prevent similar incidents from happening again, Okta has currently implemented the following: Added and improved alerting related to Okta webhook delivery Additionally, we are reviewing and enhancing additional internal alerting processes and procedures to prevent this issue from recurring in the future. To further enhance reliability, we are implementing stronger validation and assurance practices for new system component change controls.
Reported by Okta on their status page.
ResolvedSep 26 · 00:22 UTC
We sincerely apologize for any impact this incident has caused to you, your business, or your customers. At Okta, trust and transparency are our top priorities. Outlined below is the RCA summary for a recent incident where a third-party provider or downstream service experienced an issue that impacted the Okta service. We are committed to implementing improvements to the service to prevent similar occurrences. Detection and Impact: On September 15, 2026, at 06:33 UTC, Okta customers utilizing identity provider-initiated sign-on flows for Office 365 Outlook, Calendar, and People applications began encountering intermittent HTTP 401 Unauthorized errors upon redirection. End users successfully completed authentication through Okta, but were unable to reach the target applications when selecting application tiles. Root Cause Summary: An architectural update to Microsoft’s infrastructure inadvertently affected incoming requests via legacy application redirection paths, resulting in HTTP 401 Unauthorized errors. While Okta completed session authentications and policy evaluations as expected, session handoffs failed at Microsoft’s endpoints due to changes in legacy assembly handling. Okta services remained fully operational throughout the event. Remediation Steps: Okta Engineering worked directly with Microsoft to identify and escalate the issue for resolution. Okta then monitored service telemetry until Microsoft completed the deployment of a software fix across its production environments, confirming full mitigation on September 18, 2026, at 17:30 UTC. Preventive Actions: Okta is implementing dynamic runtime URL configuration capabilities to allow application tile target URLs to be updated without requiring standard release cycles. Timing: Incident start: September 15, 2026, at 06:33 UTC Incident resolved: September 18, 2026, at 17:30 UTC Duration (# of minutes): 3 days, 10 hours, and 57 minutes.
Reported by Okta on their status page.
