Okta 中断历史

1. 2026年9月3日 UTC 10:42resolved

   工程组继续调查OP1中的错误500个问题. 在此期间,用户可能会在我们的系统内遇到断断续续的问题。 我们将在今后30分钟内提供另一个最新情况,或者在获得进一步信息的情况下提前提供.

2. 2026年9月3日 UTC 11:02resolved

   工程组继续调查OP1中的错误500个问题. 在此期间,用户可能会在我们的系统内遇到断断续续的问题。 我们将在今后30分钟内提供另一个最新情况,或者在获得进一步信息的情况下提前提供.

3. 2026年9月3日 UTC 11:34resolved

   工程组继续调查OP1中的错误500个问题. 在此期间,用户可能会在我们的系统内遇到断断续续的问题。 我们将在今后30分钟内提供另一个最新情况,或者在获得进一步信息的情况下提前提供.

4. 2026年9月3日 UTC 12:00resolved

   工程组继续调查OP1中的错误500个问题. 在此期间,用户可能会在我们的系统内遇到断断续续的问题。 我们将在今后30分钟内提供另一个最新情况,或者在获得进一步信息的情况下提前提供.

5. 2026年9月3日 UTC 12:30resolved

   工程组继续调查OP1中的错误500个问题. 在此期间,用户可能会在我们的系统内遇到断断续续的问题。 我们将在今后30分钟内提供另一个最新情况,或者在获得进一步信息的情况下提前提供.

6. 2026年9月3日 UTC 13:03resolved

   奥克塔工程公司能够采取必要行动来缓解这一问题,目前正在监测稳定情况。 问题的原因和所采取行动的细节将张贴在信托基金网页上.

7. 2026年9月3日 UTC 14:09resolved

   在经过长时间的监测之后,我们确认这一问题没有再出现。 将在5个工作日内将根源分析公布于此。 我们为这对你和你的用户的影响表示诚挚的歉意.

自动翻译自官方事件更新。

1. 2026年8月14日 UTC 15:23resolved

   Okta Engineering is investigating and has determined that the incident is currently impacting email delivery to a subset of customers. During this time, customers may experience email delivery deferrals. We'll provide an update in 30 minutes, or sooner if additional information becomes available.

2. 2026年8月14日 UTC 15:39resolved

   Okta Engineering has determined that certain third-party providers were failing to receive emails from Okta. Our monitoring shows delivery rates are recovering to normal conditions and will continue to monitor until full resolution. Our next update will be in 30 minutes or sooner if additional information becomes available.

3. 2026年8月14日 UTC 16:50resolved

   Our monitoring indicates that email deferrals to the impacted third-party email service have returned to the expected baseline. Additional information will be available within 5 Business days.

4. 2026年8月21日 UTC 16:04resolved

   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: Okta detected an increase in customer support tickets regarding email delivery issues. Customers using custom email domains routed through Proofpoint experienced email delivery deferrals. During this period, affected end users were unable to receive system-generated emails, including One-Time Passwords (OTPs), account activation emails, password reset emails, factor enrollment emails, and other automated notifications. Root Cause Summary: Third-party provider Proofpoint experienced a service disruption, causing issues with email deliverability. When Okta services attempted to send emails to recipient domains whose MX records pointed to Proofpoint's infrastructure, the delivery attempts failed due to connection errors, resulting in deferred delivery. Okta's email sending infrastructure operated normally throughout the event. Remediation Steps: Okta Engineering monitored service telemetry and confirmed that email delivery returned to normal pre-incident baselines once Proofpoint restored stability to its infrastructure. Preventive Actions: Okta is defining automated alerting thresholds for email-bound and deferral rates to decrease detection time and updating runbooks to allow faster diagnosis of downstream provider disruptions. Timing: Incident start: August 14, 2026, at 5:00 AM PDT Incident resolved: August 14, 2026, at 10:04 AM PDT. Duration (# of minutes): 304 minutes Based on details provided by https://www.proofpoint.com/us/support-services

1. 2026年7月24日 UTC 13:55resolved

   经过一段时间的稳定和监测后,我们现在可以确认服务问题已经完全解决。 将在5个工作日内提供其他根源信息.

2. 2026年8月1日 UTC 03:28resolved

   我们为这起事件给您、您的企业和您的客户带来的任何影响表示诚挚的歉意。 在奥克塔,信任和透明度是我们的最高优先事项。 有关这一事件的事实概述如下。 我们致力于改进我们的服务,以防止今后再次发生。 2026年7月24日,约3:55AM PDT,奥克塔观察到了OK7,OK12,OK14和OP3的服务退化. 这一事件具体地影响了客户使用AD/LDAP授权认证和位于AWS我们西-2区域内的OAuth标志端客户。 在整个活动中,用户都遇到访问资源出错,认证失败,代理连接超时,超时,和OAuth令牌请求. 根原因摘要 其根源来自受影响地区云服务提供者内部的错误。 补救措施 云服务商恢复了连通性,奥克塔服务稳定在4:10AM PDT左右,我们的团队确认4:19AM PDT完全恢复基线业务. Okta正在积极审查和执行几项倡议,以防止今后发生。 这些措施包括:审计和改进我们处理一个区域内广泛问题的事件反应程序,并根据这一事件完善我们的监测和警报。 总持续时间(分钟): 15分钟 开始时间: 3:55 AM PDT 结束时间: 4:10 AM PDT 持续时间: 15

自动翻译自官方事件更新。

1. 2026年7月22日 UTC 15:14resolved

   请注意,我们目前仍在按计划进行维修,奥克塔工程队正在积极开展工作。 在这个扩展窗口中,客户在登录到Okta Workflows时可能会出错. 我们赞赏你的耐心,因为我们的团队努力尽快和安全地完成这一行动。 nbsp; (N) (中文(简体) ). 为了了解这可能如何影响你的组织,并查看建议的工作变通办法,请审查我们的详细支持文章: https://support.okta.com/help/s/article/okta-workflows-cell-migration-expect-behaviors-and-workaunds?language=en US。 30分钟后,或者在获得更多信息后,我们将提前提供进一步的最新资料.

2. 2026年7月22日 UTC 15:49resolved

   维持活动仍在进行中,因为我们确保安全和成功地完成迁移。 & nbsp; 我们将在30分钟内继续共享更新, 或更早地共享更新 。 同时,请参看下文关于工作变通办法和预期行为的最新指导: https://support.okta.com/help/s/article/okta-workflows-cell-migration-expected-behaviors-and-workabouts? 语言=en US (英语)

3. 2026年7月22日 UTC 16:19resolved

   我们现在在移徙活动之后看到稳定的系统运行情况。 我们的工程小组仍然积极参与监测所有服务。 核心工作流程正在恢复,客户应看到持续改善。 我们将在30分钟后提供下一次最新情况,或者在获得新信息后提前提供.

4. 2026年7月22日 UTC 16:59resolved

   经过一段时间的稳定和监测后,我们现在可以确认服务问题已经完全解决。 将在5个工作日内提供其他根源信息.

5. 2026年7月29日 UTC 23:34resolved

   我们为这起事件给您、您的企业和您的客户带来的任何影响表示诚挚的歉意。 在奥克塔,信任和透明度是我们的最高优先事项。 有关这一事件的事实概述如下。 我们致力于改进我们的服务,以防止今后再次发生。 我们认识到,这项维护工作超出了其最初沟通的窗口,而且我们在延长期间提供的最新情况没有及时告知客户。 对此我们表示歉意;改进它是我们下面预防行动的一部分。 2026年7月22日凌晨5点15分,我们北美地区的Okta Workflows(FL1细胞)开始经历影响美国第1,第2,第3,第4,第6,第7和第11个细胞的Workflows用户的问题. 在此期间,一些工作流程执行失败或过早结束,用户遇到加载Workflows Console出错. 此外,一些应用连接停止工作,需要用户手动重新认证以恢复功能. 根原因摘要 这个问题发生在计划进行的系统升级期间。 第三方供应商软件的缺陷导致升级运行时间大大超过预期。 在迁移到一个新的数据存储系统的同时,系统组件之间的通信故障使服务无法在预期窗口内恢复正常状态. 在此期间,Workflows Console没有在基础数据存储不可用时轻而易举地降解;相反,它直接向用户浮出错误. 此外,在中断期间无法刷新资质的应用连接被留在了失败状态,并且没有被自动刷新,这就是为什么在升级完成后,一些出错还在继续,直到受影响的连接被重新授权. 补救措施 第三方供应商确认该组稳定在8:34AM PDT. 稳定后,Okta工程公司恢复了受影响服务,以清理已失效的配置缓存. 在此期间遇到OAuth令牌刷新出错的任何客户都必须手动重新授权任何应用连接. 9:33AM PDT恢复了全部功能. 如果您仍然受到影响: 手动重新授权Workflows Console中受影响的连接证书(参见 KB: Okta Workflows: Cell migration Expected Behaviers and Workrounds). 在窗口中失败的工作流处决可以使用正常程序重新运行; 联系Okta Support, 如果你愿意帮助识别受影响的处决. 预防行动 为了防止类似事件的发生,奥克塔采取了以下步骤. 我们已经在全舰队范围内控制了所有进一步的数据存储引擎迁移,直到我们的第三方供应商为已确认的缺陷部署一个固定装置,并证实可以安全进行。 我们还在更新Workflows Console系统,以便在基础设施暂时无法使用时快速故障并自动恢复,确保用户看到重联状态而不是原始系统出错. 与此同时,我们正增加直接自动监测和警报,防止集群汇合故障,以确保在维护窗口期间能更快地检测。 最后,我们正在改进在长期维护期间的沟通方式,包括更及时地提供现状网页和进展/完成最新情况。 对于Workflows可靠性或行进图的问题,您的Okta账户团队可以提供帮助. 总持续时间(分钟):258分钟(4小时18分) 开始时间:5:15 AM PDT 结束时间:9:33 AM PDT 持续时间:258分钟

自动翻译自官方事件更新。

1. 2026年7月13日 UTC 21:23resolved

   我们的工程小组对受影响的预览环境采用了潜在的固定方法,并正在积极监测该系统的恢复情况。 我们将在30分钟内提供另一个最新情况,或者在获得新信息后更早。 我们为任何不便深表歉意.

2. 2026年7月13日 UTC 21:39resolved

   我们的工程组应用了一个固定设备,我们正在观测我们的OP2预览环境的服务恢复。 我们正在密切监测这一系统,并将在30分钟内再次提供最新情况.

3. 2026年7月13日 UTC 21:53resolved

   我们确认,OP2预览环境已完全稳定,而更早的问题已完全解决. 将在5个工作日内提供其他根源信息.

4. 2026年7月21日 UTC 01:57resolved

   我们为这起事件给您、您的企业和您的客户带来的任何影响表示诚挚的歉意。 在奥克塔,信任和透明度是我们的最高优先事项。 有关这一事件的事实概述如下。 我们致力于改进这项服务,以防止今后发生这一事件。 侦测与影响:2026年7月13日1:01 PM PT,奥克塔内部监控警告我们团队EMEA预览细胞环境出现高发出错. 在此期间,EMEA预览细胞环境中的所有客户都受到影响,经历了认证失败和服务缓慢. 管理员和终端用户在尝试在Okta服务中签名或访问时可能遇到"内部服务器出错"等消息. Root Cause Summary:事件在预定的服务升级过程中被触发. 一次配置错误导致EMEA预览单元格集群无意中收到一个不正确的版本的关键基础设施路由组件. 这一更新打破了内部联网路线,妨碍了本来健康的基础设施各部分之间的沟通。 由于请求无法到达核心应用程序,导致普遍服务出错和认证失败. 补救步骤:奥克塔的工程团队确定了问题,并立即开始部署之前稳定的版本的路由配置. 在回滚后,工程师系统重启了受影响的服务(包括网关和代理)来恢复内部连接. 这些行动成功地解决了这个问题,并且以2:20 PM PT完全缓解了客户的影响. 预防行动:我们正在完善业务程序,以加强服务稳定性。 这包括正在进行的提高汽车探测和监测能力的工作,帮助我们更有效地查明并处理潜在的问题。 总持续时间(分钟):79分(1小时19分) 起步时间: 1:01 PM PT 结束时间:2:20 PM PT

自动翻译自官方事件更新。

1. 2026年7月7日 UTC 20:50resolved

   Okta工程公司发现一个影响Okta工作流量的问题,目前正在采取措施进行补救。 客户在Okta Workflows控制台、API端点和入网点中可能看到500个出错或超时。 我们将在今后30分钟内提供另一个最新情况,或者在获得进一步信息的情况下提前提供.

2. 2026年7月7日 UTC 21:03resolved

   Okta Workingflows的问题已经得到解决。 所有的工作流量现在都正常处理。 将在5个工作日内将根源分析公布于此。 我们对此可能造成的不便表示歉意.

3. 2026年7月15日 UTC 15:22resolved

   我们为这起事件可能对你、你的生意或你的客户造成的任何影响表示诚挚的歉意。 在奥克塔,信任和透明度是我们的最高优先事项。 有关这一事件的事实概述如下。 我们致力于改进这项服务,以防止今后发生这一事件。 检测与影响:2026年7月7日1:01 PMPDT,Okta内部监控和客户报告提醒我们团队注意用户访问北美Okta OK14手机Workflows的问题. 在此期间,FL14上的客户在从管理员门户导航到Workflows或试图通过SSO登录到Workflows Console时可能遭遇了HTTP 500,503或504Gateway超时出错. 现有会议可能间歇性出错。 排行和点播工作流程,内置钩子,和webhooks可能经历了出错和超时. 此外,飞行中的处决也暂停。 根源摘要:这一事件发生在计划向FL14牢房部署释放202.07.0人期间。 在部署过程中,一个负责执行计划更新的服务舱被提前终止。 这一早期的终止导致了出乎意料的,长生的数据库连接,最终导致细胞主数据库的连接耗尽. 补救步骤:在收到警报和客户报告后,小组于PM PDT12:44开始诊断. 到了1: 30 PM PDT,他们隔离并取出服务舱 进行schema更新. 这使得数据库连接可以清空,在1:45 PM PDT前恢复全部服务. 预防行动:为了防止今后发生,奥克塔致力于加强我们的基础设施稳定性并增强我们的监测能力。 我们目前正在对我们的部署进程和警报系统进行战略改进,以确保更快的检测、反应和更大的复原力。 会期:67分钟

自动翻译自官方事件更新。

1. 2026年6月26日 UTC 15:22resolved

   Our Engineering team has identified the issue, and we will continue monitoring the issue. We will provide another update within the next 15 minutes, or sooner if additional information becomes available.

2. 2026年6月29日 UTC 23:50resolved

3. 2026年6月30日 UTC 15:01resolved

   The Root Cause Analysis (RCA) details previously posted in this update were published in error and belonged to a separate incident that occurred on June 22nd (I-10858). We sincerely apologize for any confusion this may have caused. Our formal RCA process for this OK11 custom domains incident (I-10874) is still actively underway. We remain committed to transparency and will provide an accurate, dedicated RCA for this disruption within 5 business days (expected late July 6, 2026). Thank you for your patience.

4. 2026年7月6日 UTC 22:01resolved

   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 June 26th at 7:43 AM (PT), Okta was alerted to customer reports of connection issues and authentication failures when accessing custom domains. The incident was isolated to OK11 and normal connectivity was restored at 7:53 AM (PT). Root Cause Summary: Okta Engineering identified that the root cause of the issue originated during a custom domain traffic migration in OK11 on June 25th at 10:47 AM (PT), the new routing infrastructure became resource-constrained under increased traffic volume the next day. This resulted in TCP connection resets and errors sent to clients attempting to access custom domains. Remediation Steps: Once the source of the issue was identified, Okta engineering immediately mitigated the issue by reverting custom domain traffic back to the previous infrastructure, restoring normal connectivity within minutes. Preventative Actions: To prevent future incidents, the routing infrastructure was scaled to prevent recurrence. Okta will work to implement enhanced monitoring and alerting, as well as updated auto-scaling policies to ensure routing infrastructure maintains adequate capacity during traffic fluctuations and future infrastructure improvements. Duration (# of minutes): Total Duration (Minutes): 53 minutes Actual Time: 7:00 AM - 7:53 AM PT

1. 2026年6月22日 UTC 22:02resolved

   The Okta Engineering team has taken steps to mitigate the issue. We have observed that the errors have been reduced and is continuing to subside. We are monitoring the situation closely and will provide further updates in 15-30 minutes as we move toward full mitigation.

2. 2026年6月22日 UTC 22:33resolved

   Internal monitoring confirmed that the EU1 environment has fully recovered and is operating normally. A full Root Cause Analysis (RCA) will be made available within 5 business days. We apologize for any disruption this may have caused.

3. 2026年6月30日 UTC 14:43resolved

   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 June 22nd, 2026, at 2:08 PM PDT, Okta internal monitoring alerted our team to errors in the EU environment. During this period, administrators and end users may have experienced intermittent 500 Internal Server Error and 429 Rate Limit responses when attempting to access Okta services. Root Cause Summary: The incident was triggered by an unexpected scaling down of the application cluster during scheduled maintenance of the environment. This change accidentally overwrote the custom capacity settings for several of our applications. This caused the system to automatically revert to its lowest default capacity, drastically reducing the amount of user traffic it could handle simultaneously. As a result, the remaining servers were immediately overwhelmed by the normal volume of user requests, leading to system slowdowns, errors, and "too many requests" blockages for our customers in the impacted cell. Remediation Steps: Okta's engineering team identified the root cause issue at 2:44 PM PDT. The team mitigated the issue by scaling up resource capacity, completely stabilizing service health back to normal levels by 2:48 PM PDT. Preventative Actions: In order to prevent similar incidents from happening again, Okta is currently reviewing the following: - Strengthen guardrails by improving our validation tools and multi-environment review processes to automatically detect and flag unexpected server capacity changes before they're applied. - Accelerate system monitoring by implementing enhanced monitoring thresholds to instantly detect and report infrastructure capacity drops before they can impact end users. - Optimize failover protocols by auditing critical alert paths for maximum reliability while establishing a clear, structured communication plan for when automated backup systems are triggered. These learnings work to prevent similar incidents from happening again. Duration (# of minutes):40 minutes

1. 2026年6月2日 UTC 11:21resolved

   Engineering is still investigating the issue, recent actions that were taken show errors subsiding.

2. 2026年6月2日 UTC 11:40resolved

   The Okta Engineering team has observed that the errors have been reduced. We are monitoring the situation closely and will provide further updates as we move toward full mitigation.

3. 2026年6月2日 UTC 12:07resolved

   Okta Engineering has confirmed that the issue has been resolved. An RCA will be provided in five business days. We apologize for any inconvenience this may have caused.

4. 2026年6月10日 UTC 02:19resolved

   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 June 2nd, 2026, at 2:36 AM PT, Okta internal monitoring alerted our team to elevated errors in the OK9 environment. During this period, administrators and end users may have experienced intermittent 500 Internal Server errors when trying to access Okta services. Additionally, Admins may have encountered error messages when fetching certain records. Root Cause Summary: The incident was triggered by a misconfiguration introduced during a scheduled maintenance of the environment. This maintenance introduced an error that caused connectivity issues within specific infrastructure components. Only a small percentage of the infrastructure was affected during this period. Remediation Steps: Okta's engineering team identified and isolated impacted infrastructure at 4:01AM PT. These actions successfully addressed the issue, and normal operations were restored by 4:17 AM PT. Preventative Actions: In order to prevent similar incidents from happening again, Okta is currently reviewing the following: Incident response processes, procedures, and investigation tools to more rapidly diagnose similar issues in the future. Risk evaluation processes to include expanding error types and adding additional appropriate corresponding alerts and monitoring associated with vulnerability updates. These learnings work to prevent similar incidents from happening again and, in cases like these, allow Okta to respond faster when possible. Duration (# of minutes): 100

1. 2026年5月1日 UTC 00:28resolved

   The Okta Engineering team has successfully resolved the service instability that was causing system timeouts. Okta engineering has confirmed that errors have subsided, and we have transitioned into a monitoring phase to ensure continued stability. We sincerely appreciate your patience while our team worked to identify and resolve the issue.

2. 2026年5月1日 UTC 01:01resolved

   Internal monitoring confirmed that the OP1 environment has fully recovered and is operating normally. A full Root Cause Analysis (RCA) will be made available within 5 days. We apologize for any disruption this may have caused.

3. 2026年5月8日 UTC 02:51resolved

   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 April 30th, 2026, at 10:57 AM PT, Okta internal monitoring alerted our team of login issues for users accessing Okta Preview Cell 1. During this period, customers may have received 500 errors for query timeouts and were unable to log in. Root Cause Summary: The incident stemmed from a database query change. The updated query intermittently exceeded its timeout limit across several login endpoints. Consequently, users experienced 500 errors and were unable to log in. Remediation Steps: Upon receiving the alerts, Okta Engineering immediately launched an investigation. By 1:02 PM PT, the team took initial mitigation steps to resolve the issue, however these steps did not resolve the issue. The incident response team continued to triage and diagnose the issue and identified the root cause related to the updated database query change at 4:50 PM PT. The team reverted the new query behavior at 5:00 PM PT in Preview Cell 1, and full service functionality was restored by 5:05 PM PT. Preventative Actions: In order to prevent similar incidents from happening again, Okta is currently reviewing the following: -Reviewing incident response processes and investigation tools to more rapidly diagnose similar issues in the future -Risk evaluation processes associated with query updates -Alerts and monitors associated with the database proxy These learnings work to prevent similar incidents from happening again and, in cases like these, allow Okta to respond faster when possible. Duration (# of minutes): 375

1. 2026年4月29日 UTC 22:42resolved

   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: Customers using the third-party service Kolide began reporting that attempts to sign in to their orgs redirected to an unrelated tenant and received an HTTP 400 error with the message “Login Failed - 400: Bad Request Error Code: GENERAL_NONSUCCESS” Root Cause Summary: Kolide has confirmed for Okta that an incident occurred with their Device Trust SAML authentication system, resulting in some users being redirected to an incorrect service provider after completing authentication. This resulted in users receiving a 400 error. Kolide reported that users were unable to access their intended application, any unauthorized applications, or any unauthorized environments. Remediation Steps: Okta Support advised customers that they could temporarily disable their Kolide integrations to allow their users to successfully access their services. Timing: Kolide reports: Incident start: April 22, 2026, at 8:24 AM PDT Incident resolved: April 22, 2026, at 8:30 AM PDT Duration (# of minutes): 6 Minutes

1. 2026年4月13日 UTC 20:33resolved

   Okta has identified the issue impacting Access Request job processing and Engineering Teams are working to restore the service. We are rolling out the fix for this issue in 30 minutes and will provide another update once the fix is rolled out.

2. 2026年4月13日 UTC 20:59resolved

   Okta has identified the root cause of the issue affecting Access Request job processing as of 1:00 PM PT. A resolution was implemented at 1:45 PM PT, and the service is now fully operational for new submissions. The engineering team is currently working to restore and process any requests submitted during the disruption period. We will provide another update within the next 30 minutes, or sooner if additional information becomes available.

3. 2026年4月13日 UTC 21:29resolved

   While new Access Request job processing has been restored, Okta is also working to resolve the issue affecting in-flight Access Request job requests processed during the disruption period.  The fix for this issue is expected to be implemented around 5:00pm PT.  Okta will provide another update at 5:00pm PT or sooner if one becomes available.

4. 2026年4月14日 UTC 00:25resolved

   The issue with in-flight Access Request job requests processed during the disruption period has also been resolved. All Access Request jobs are now processing normally. A root cause analysis (RCA) will be posted here within five business days. We apologize for any inconvenience this may have caused.

5. 2026年4月21日 UTC 23:16resolved

   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 are the facts regarding this incident. We are committed to implementing improvements to the service to prevent future occurrences of this kind. Detection and Impact: On April 13, 2026, at 11:51 AM PST, an incident was reported where Okta Identity Governance (OIG) access requests stalled in the "In Progress" state indefinitely across all environments. The system accepted initial submissions and first-level approvals, but failed to trigger subsequent automated tasks like assigning users to apps/groups or running delegated workflows. . Root Cause Summary: During a recent update deployment, new tasks inadvertently moved to a 'LOCKED' status without implementing the necessary logic to transition them back to 'OPEN.' This caused the tasks to become permanently hidden, preventing the automated execution of the action associated with them. Remediation Steps: Okta's engineering teams promptly responded, initiating immediate detection and diagnosis. Corrective measures, including a code fix deployed to all cells, were implemented to prevent any new access requests from becoming stuck. A remediation migration successfully transitioned most affected requests to a fixed state. Normal functionality was fully restored by April 13, 2026, at 5:18 PM PST, following the completion of a final migration to unblock remaining requests.On April 14, 2026, Okta took further steps to resolve in-flight requests that were stuck, moving them to a final, terminal state. Preventative Actions: Okta is taking several steps to prevent this issue from recurring. These include enhanced testing, deployment of safeguards, and improvements to our monitoring and alerting systems. Duration (# of minutes): 434

1. 2026年3月24日 UTC 23:32resolved

   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: Okta internal monitoring alerted our engineering team to disruptions to the Okta status page and the commercial support portal. Okta Engineering identified a service disruption with our third-party provider and confirmed the impact. During the disruption, customer admins were unable to access the Okta Support Center (support.okta.com) to log support cases or view the primary status page (status.okta.com). Root Cause Summary: Okta's third-party provider, responsible for hosting the Okta Support Center and status page, experienced a service disruption. The third-party provider identified a version mismatch between their application and database layers as the technical trigger. This mismatch resulted in internal server errors and login failures, rendering the Okta Support Center and status page inaccessible for a portion of their disruption. Remediation Steps: Okta teams posted an admin banner within the Okta Admin Console to provide visibility into the disruption and offer a phone number for customers who needed to log support cases manually while the Okta Support Center was unavailable. Services were fully restored after the third-party provider successfully deployed a fix-forward release to the impacted infrastructure, which restored login access. Preventive Actions: As part of Okta's commitment to operational resilience, we have optimized our vendor engagement matrix to accelerate incident mitigation and downstream coordination. We are also conducting an expanded audit of external dependencies to formalize alternative response procedures within our disaster recovery plans. Simultaneously, Engineering has enhanced real-time monitoring and alerting for service endpoints, enabling faster detection and resolution. Timing: Incident start: March 16, 2026, at 08:58 PM PDT Incident resolved: March 16, 2026, at 11:34 PM PDT Duration (# of minutes): 156 minutes

1. 2026年3月13日 UTC 18:48resolved

   At around 11:20AM PT, Okta Engineering has confirmed that the issue has been resolved in both cells, EU1 and OK1. An RCA will be provided in five business days. We apologize for any inconvenience this may have caused.

2. 2026年3月20日 UTC 20:35resolved

   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 are the facts regarding this incident. We are committed to implementing improvements to the service to prevent future occurrences of this kind. Detection and Impact On March 13, 2026, at 10:49 AM PT, Okta detected a service degradation that prevented some customers on the OK1 and EU1 cells from performing directory operations, viewing or searching for users, groups, and devices in the Okta Admin Console. Customers may have experienced "Invalid search query" messages or 5xx errors. This issue also affected several API endpoints related to users, groups, and devices, which may have impacted customer integrations relying on this functionality. End-user authentication was not impacted. Root Cause Summary The root cause of this incident was a planned configuration change that exposed a bug in the underlying service, resulting in system errors and disrupting both directory-based APIs. Remediation Steps Upon detection, Okta's engineering teams initiated incident response procedures. Once the problematic configuration change was identified as the source of the errors, it was immediately reverted. After the reversion was applied and verified, full functionality was restored to all impacted customers. Preventative Actions Okta is taking steps to prevent future occurrences of this kind, including enhancing our testing processes, hardening and improving our configuration rollout strategy, and upgrading our monitoring and alerting systems for enhanced detection. Start Time: 03/13/2026 10:17 AM PT End Time: 03/13/2026 11:21 AM PT Duration (# of minutes): 64

1. 2026年2月4日 UTC 12:37resolved

   Okta has implemented a fix for the LDAP issue affecting the OK9 environment. We are observing signs of service recovery and confirmed improvements from customers. We will continue to monitor the situation closely to ensure full resolution. We are monitoring the situation closely and will provide further updates within the next 30 minutes.

2. 2026年2月4日 UTC 12:50resolved

   This incident has been resolved. Internal monitoring and customer reports confirm that the LDAPi system in OK9 has fully recovered and is operating normally. We will continue to closely monitor the service to ensure stability. A full Root Cause Analysis (RCA) will be made available within 5 days. We apologize for any disruption this may have caused.

3. 2026年2月11日 UTC 18:45resolved

   On February 4th, 2026, at 3:33 AM PT, Okta received customer reports of authentication failures within the OK9 (EMEA) cell. Customers attempting to access LDAP interface services encountered certificate validation errors related to hostname mismatches, preventing successful authentication. Root Cause Summary: The incident was triggered by a misconfiguration introduced during a scheduled update of our LDAP interface to a new configuration source on February 4th 2:24 AM PT. This update inadvertently applied an incorrect SSL certificate profile to the LDAP interface within the OK9 environment. This misconfiguration caused certificate validity errors, resulting in connection issues when attempting to use LDAP services. Remediation Steps: Once the source of the issue was identified, Okta engineering team rolled back changes at 4:07 AM PT. These actions successfully addressed the issue and restored normal operations by 4:26 AM PT. Preventative Actions: To prevent future incidents, Okta has updated synthetic tests and enhanced monitoring. Teams also plan to add new tooling to improve changes to the LDAP service certificates. In addition, we are reviewing our internal processes and procedures, refining our automated rollback processes to further reduce the customer impact time for similar issues in the future. Duration (# of minutes): Total Duration (Minutes): 122 minutes Actual Time: 02:24 AM PT - 04:26 AM PT

1. 2026年1月28日 UTC 19:24resolved

   We are seeing significant and steady system stability as our third-party provider recovery continues in the EU-West-1 region. We will continue monitoring the service to ensure a full recovery. We will provide another update in 60 minutes or as soon as more information becomes available.

2. 2026年1月28日 UTC 19:36resolved

   The third-party provider has confirmed that the issue has been resolved. A root cause analysis (RCA) will be posted here within five business days.

3. 2026年2月5日 UTC 01:26resolved

   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 January 29th, 2026, at 8:28 AM PT, Okta internal monitoring alerted our team of intermittent connectivity issues accessing Okta Cell 9 (EMEA). During this period, customers may have experienced intermittent errors establishing network connections and latency when trying to access Okta services. Clients configured to retry failed connections likely saw successful connectivity on secondary attempts. Root Cause Summary: The incident stemmed from a failure of a component that manages configuration changes to the networking infrastructure with our Cloud Service Provider (CSP) in the region hosting Okta Cell 9. Remediation Steps: Immediately upon receiving the alerts, Okta Engineering began investigating several isolated spikes but determined that cell health was stable. At 9:35 AM PT, Okta Engineering received more alerts and immediately initiated incident response procedures. At 9:51 AM PT, Okta Engineering began working with the CSP to diagnose the issue. At 10:13 AM PT, the latency began to stabilize. At 11:22 AM PT, the issue was resolved. Preventative Actions: To prevent similar incidents from recurring, Okta Engineering is improving our monitoring, working with our CSP to enhance their monitoring, and reviewing incident response processes associated with this event. Duration (# of minutes): 186

4. 2026年2月11日 UTC 18:40resolved

1. 2026年1月22日 UTC 21:46resolved

   We are continuing to monitor the third-party email service provider's progress toward a resolution. At this time, we have not received an estimated time for recovery (ETR). If you are attempting to sign in and have configured alternative MFA factors (such as Okta Verify, SMS, or Security Keys/Biometrics), we recommend using those options to avoid delays associated with email delivery. Our engineering teams remain on standby to verify service restoration the moment it begins. We will continue to provide updates as soon as the impacted provider shares new information.

2. 2026年1月22日 UTC 23:24resolved

   We're continuing to track the ongoing service disruption with the third-party email provider. We appreciate your patience while we await the provider's resolution of the root cause. We'll post our next update in 90 minutes or as soon as we have a significant change in status.

3. 2026年1月23日 UTC 00:46resolved

   The third-party email provider has identified the root cause as a service infrastructure issue within the North America region. They are currently implementing load-balancing configurations to stabilize the environment. While recovery is underway, users may continue to experience intermittent delays or failures in receiving emails. We are monitoring the provider's progress and will provide another update as they move toward full resolution.

4. 2026年1月23日 UTC 03:55resolved

   The third-party provider continues to see improvements across their impacted North American infrastructure. While our internal systems remain healthy, our team is on standby to validate the restoration of all external dependencies. We will provide a final update once the provider confirms that their services have fully returned to normal operations.

5. 2026年1月23日 UTC 06:46resolved

   The third-party provider has confirmed that a fix has been successfully deployed. A root cause analysis (RCA) will be posted here within ten business days. We sincerely apologize for the impact this had on you and your users.

6. 2026年1月30日 UTC 22:34resolved

   Following is the RCA summary for a recent incident where a third-party provider or downstream service experienced an issue that impacted the Okta service Timing: Incident start: January 22, 2026, at 10:55 AM PST Incident resolved: January 22, 202,6 at 7:50 PM PST Detection: The issue was initially identified through customer reports that they were not receiving expected email notifications. Okta Engineering confirmed the service disruption after internal monitoring indicated a high volume of deferred email delivery attempts to specific third-party domains. Impact: Customers across all Okta cells with email addresses hosted by Microsoft Exchange Online may have experienced intermittent delays or failures in receiving automated email notifications, such as Multi-Factor Authentication (MFA) codes and enrollment links. Okta services remained healthy and attempted to resend deferred messages. Root Cause: Microsoft reports that it experienced a service issue within its North American data centers during a planned maintenance activity. As a result, emails sent from Okta to the affected provider resulted in “soft bounce” errors, indicating that the provider's servers were temporarily unable to accept the messages. Remediation Steps: To mitigate the impact on users attempting to sign in, Okta recommended using alternative MFA factors, such as Okta Verify, security keys, or SMS, to bypass delays associated with email delivery. Okta Engineering continuously monitored the third-party provider's recovery efforts and validated that mail delivery returned to baseline levels once the provider stabilized their environment.

1. 2026年1月20日 UTC 16:04resolved

   We've identified that the service interruption is due to an issue with a third-party provider. We are actively working with the provider to ensure a swift resolution and are closely monitoring progress. We will provide further updates as more information becomes available.

2. 2026年1月20日 UTC 16:35resolved

   We are continuing to monitor progress with our third-party provider. The provider is currently implementing mitigation steps, and we are seeing signs of recovery. Several customers have already confirmed that service has been restored on their end. We are working to ensure this resolution is consistent across all accounts. We will provide the next updates within 30 minutes, or sooner if additional information becomes available.

3. 2026年1月20日 UTC 17:10resolved

   Our third-party provider is continuing their recovery efforts. While we are no longer seeing active errors, we remain in a period of close monitoring as they work toward a final resolution. We recognize that some users may still experience residual effects; our Support teams are working with them to resolve these errors. Our next update will be in 60 minutes or sooner if additional information becomes available.

4. 2026年1月20日 UTC 17:21resolved

   Our third-party provider has confirmed that a fix has been successfully deployed. A root cause analysis (RCA) will be posted here within ten business days. We sincerely apologize for the impact this had on you and your users.

5. 2026年1月26日 UTC 18:31resolved

   Following is the RCA summary for a recent incident where a third-party provider or downstream service experienced an issue that impacted the Okta service. Timing: Incident start: January 19, 2026, at 10:10 AM PST Incident resolved: January 20, 2026, at 11:49 AM PST Detection: Okta teams were notified via customer cases and an increase in Google Workspace import errors. Impact: Any customers performing Google Workspace imports during the incident window may have encountered an error stating “UserImportJob: Failed to download users. Json field=primaryEmail does not exist for object=[...]” Root Cause: Google Workspaces, a third-party provider, confirmed that a faulty code change introduced caused certain fields, such as primary email addresses, to be missing in API call results. As a result, Okta imports from Google Workspace could not complete, leading to import failures. Google provides additional details for this disruption: https://www.google.com/appsstatus/dashboard/incidents/9q5n4sfDnxYzHj8FxEua Remediation Steps: Okta teams soon identified that a provider-side disruption was the cause of the incident and opened a formal support case to track the resolution. The third-party provider resolved the incident by rolling back a faulty code change and restoring the missing metadata. Recovery occurred in stages, with some customers successfully remediated before others. Okta teams monitored the recovery in real-time and confirmed successful import signals across multiple impacted customers before standing down.

1. 2026年1月3日 UTC 01:52resolved

   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 are the facts regarding this incident. We are committed to implementing improvements to the service to prevent future occurrences of this kind. Detection and Impact: On December 26, 2025, at 3:27 AM PST, Okta engineering was alerted to increased errors in US Cell 6. During this time, US Cell 6 experienced errors, connection timeouts, and slow responses while attempting to access resources. Admins would have seen a banner on the admin portal stating that the cell was in read-only mode. Root Cause Summary: Okta has determined that the issue was caused by an outage with our cloud service provider. All instances fully recovered by 5:43 AM PT. Remediation Steps: Upon detection, Okta's engineering teams immediately began diagnosing the issue and worked with our cloud service provider to resolve the issue. In addition, the Incident response teams continued to review and analyze the incident, applying additional measures to improve service availability for end-user authentications. Preventative Actions: Okta is taking steps to prevent a recurrence of this issue. We are making improvements to our monitoring and response procedures to more quickly diagnose and recover from this kind of failure in the future. Total Duration: 2 hours and 16 minutes Start Time: December 26, 2025, 03:27 AM PT End Time: December 26, 2025, 05:43 AM PT

1. 2025年12月14日 UTC 16:40resolved

   The Okta Engineering team is continuing to work with our third-party vendor and addressing this issue with urgency related to the custom domain email delivery issues.

2. 2025年12月14日 UTC 16:42resolved

   The next update will be posted in the next 60 minutes.

3. 2025年12月14日 UTC 17:50resolved

   Our Engineering team is continuing to work with the third-party provider on mitigation actions to help resolve this outstanding issue. We are treating the issue with the utmost urgency to restore our services as soon as possible. The next update will be provided within the next 60 minutes or sooner, if additional information becomes available.

4. 2025年12月14日 UTC 18:48resolved

   We have identified a potential root cause of this issue, and are currently investigating next steps towards resolution. We will provide the next update in 60 minutes, unless new information becomes available.

5. 2025年12月14日 UTC 19:39resolved

   This issue has been successfully resolved as of 11:07AM PDT. All services have been restored. If you continue to see issues, please update your support case for assistance. Additional root cause information will be available within 5 Business days.

6. 2025年12月23日 UTC 14:49resolved

   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 are the facts regarding this incident. We are committed to implementing improvements to the service to prevent similar future occurrences. Detection and Impact: On December 14, 2025, at 3:01 a.m. PST, Okta detected an issue that prevented email delivery for customers using custom email domains. This affected end-users' ability to receive emails for Multi-Factor Authentication (MFA), password resets, registration activation, account lockout notifications, and other notification emails, such as rate-limit notifications for administrators. Root Cause Summary: Okta has determined that the issue was caused by an unintended configuration change on our Mail Transfer Agents (MTAs). This change incorrectly routed emails from custom domains without proper DMARC sender authentication. As a result, email service providers rejected the emails, causing the delivery failures. Remediation Steps: Upon detection, Okta's engineering teams immediately began diagnosing the delivery failures. After identifying the incorrect routing, we updated the configuration to ensure emails were sent through the appropriate authenticated channels. Normal email functionality was fully restored after the updated configuration was applied. Preventative Actions: Okta is taking several steps to prevent a recurrence of this issue. We are enhancing our monitoring and alerting for email services and improving our configuration management tools to add further safeguards. Duration (# of minutes):1140