58 Neo4j Aura incidents · 2023年12月 — official updates, affected components, duration and resolution details.
我们正在调查一个影响Aura控制台控制台的问题
我们已确定了问题的根源,并正在研究解决办法.
我们继续努力解决这一问题.
我们已取得良好进展并正在恢复有问题的部分.
我们已经部署一个固定装置,受影响的服务正在恢复.
所有受影响的部件现已完全恢复.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
已经查明了问题,仍有一些实例,目前正在审查为解决受影响的实例而采取的步骤.
所有情况都可用,为了解决剩余的少量情况,采取了人工步骤来解除封锁.
自动翻译自官方事件更新。
我们的小组已查明一个问题,即收集奥拉事件的衡量标准。 这将影响衡量的能见度和转发。 我们目前正在调查这一问题.
我们继续调查奥拉度量衡问题.
自上次更新以来,调查继续进行。 问题已经确定,我们监测这项服务从退化中恢复过来。 我们确认这个问题现已得到解决.
自动翻译自官方事件更新。
We have identified an issue currently that could result in unexpected query failures when using the trim() Cypher function. Investigations into the cause are in progress.
We have found the issue and are working on a fix. A small percentatge of queries using trim may still err. VDC customers with databases set to highest are not impacted at all unless they pause and start their instances.
We are testing the fix for the trim() Cypher function issue. We will update before we begin our deployment into the Aura environment.
We are actively validating the fix for the trim() Cypher function. Further updates will be provided before we begin deploying to Aura instances
We continue to validate the fix for the trim() Cypher function. Further updates will be provided before we begin deploying it to Aura instances.
The fix for the trim() Cypher function is undergoing testing and validation before deployment. Further updates will be provided before we begin deploying it to Aura instances.
Development has completed on the hot-fix for this issue, and we are finalizing the rollout plan for Aura.
We are actively working on addressing the issue. The fix for the trim() Cypher function is undergoing testing and validation currently before deployment. Further updates will be provided before we begin deploying it to Aura instances.
The fix to the trim() Cypher function has passed testing and validation and is now being deployed.
The fix to resolve the issue has now completed deployment to the Aura service and we are monitoring the situation.
We have monitored the fix and found the service to be stable. This incident is now considered resolved.
我们现在正在调查一个问题.
我们正与工程小组合作,目前调查工作正在取得进展.
我们正在与工程小组合作,并继续在目前的调查中取得进展.
我们已查明造成目前问题的原因,并正在积极努力解决该问题.
我们正在部署解决办法的第一部分,并正在继续积极推动全面解决办法。 我们期待一个ETA 大约1小时后.
我们已查明了受到影响的几类事件,并继续在这个时候采取补救措施.
我们已部署一个配置固定装置,目前正在努力解决受影响的子事件.
随着配置固定的部署,我们正在继续解决仍然受到影响的一些情况.
我们正在继续解决仍然受到影响的一些情况.
我们继续解决仍然受到影响的一些情况.
我们继续解决仍然受到影响的一些情况.
AURADB虚拟专用云和AURADB Business Critical 现在应该全部固定. 我们继续解决那些仍然影响AuraDB专业和自由的案例.
我们继续解决那些仍然影响AuraDB专业和自由的案例.
我们继续解决仍然影响到AuraDB专业和自由的一些案例.
我们继续解决仍然对AuraDB专业和自由公司产生影响的少数案例
我们继续处理一些仍然影响到AuraDB专业和自由的事例
我们继续处理仍然在AuraDB专业和自由级别下受到影响的少数案例.
我们在所有AuraDB专业案例中都讨论了这一问题。 Aura Free仍然可以受到影响. 我们将继续监测和修复剩余的数据库.
我们继续处理仍然受到影响的一小部分自由事件.
我们正在继续密切监测局势,以处理任何进一步的问题.
我们正在继续监测任何其他问题.
所有已查明的事例都已得到纠正并继续监测。 就任何其他问题与客户联系.
所有解决办法都已部署,问题现已标为已解决.
发生了什么事? 周四,Jul 23,2026 10:33 UTC向Aura部署了一个配置变化,无意中改变了数据库实例内存分配的计算方式. 因此,一个子集事件接收到的内存不足,导致一些数据库事件无法使用或无法完成更新. 被调整的内存分配导致记忆外状况,导致数据库事件由于内存资源不足而再三重启,或成为被卡住的更新. 这个问题影响到多个云供应商和多级产品。 问题一经确定,我们立即恢复了配置变化,防止其他任何情况收到不正确的配置。 在协调世界时2026年7月23日11:56周四之前,已部署已更正的配置投产. 然而,已经收到错误配置的数据库实例需要个人采取恢复行动,然后才能恢复正常运作。 至协调世界时2026年7月23日星期四17:59,所有已知的影响客户的数据库事件被找回. 监控持续到次日,事件于协调世界时2026年7月24日(Jul 24,2026年16:30)周五完全解决. ** 服务是如何受到影响的** 主要对客户的影响是,若干AuraDB数据库实例无法使用或进入了退化状态。 受影响的情况无法完成例行的软件更新,在某些情况下,由于内存分配不足,一再重启。 * ** 服务可用性:** 客户的影响因服务级别而异。 无法提供高可用性的AuraDB专业案例,其服务中断程度最大,一个子集无法使用,无法处理读取或写作。 对于受影响的AuraDB Business Critical and Virtual District Cloud \(VDC\)案例,影响一般限于暂时丧失容错能力,同时维持服务可用性. 在少数情况下,商业临界和VDC也变得无法使用。 * ** Stuck最新消息**: 其他实例仍然可用,但被卡在"更新"状态下,这阻碍了客户启动的操作,如大小调整或配置改变等. * ** 跨平台范围**: 这一影响涉及所有三个支助云供应商和多个区域,影响到全球客户。 客户支助案件被提起,我们的小组按优先顺序对受影响情况进行分类和人工恢复。 大多数AuraDB项目继续正常运行。 通过恢复每个受影响案例的配置和有针对性的人工恢复,充分减轻了客户的影响。 我们现在在做什么? 我们对这一事件进行了透彻的分析,并确定了以下行动: * ** 预防** * ** 改进部署验证:** 我们正在加强发布验证程序,以更好地确定配置变化。 * ** 构成部分脱钩**: 我们正在评估对各部分部署顺序的改进,以降低将意外变化纳入释放的风险。 * ** 逐步推出战略**: 我们正在审查受影响部分的推出过程,使其与用于其他关键部分的推出控制相一致。 *** 检测** * 更好地提醒**: 我们正在加强监测工作,以便更快、更可靠地发现故障率的异常上升。 * ** 军事** * ** 安全配置部署:** 我们正在改进如何部署生产配置的改变,以便它们能够被禁用或更快地回滚,而不需要更广泛的软件发布。 * ** 较快的人工回收工具**: 我们正在改进我们的恢复工具,以缩短查明和人工恢复受影响事件所需的时间。 我们承认这一事件造成的干扰,并对受影响的客户造成的影响表示歉意。 我们完成了立即采取的纠正行动,上述较长期的改进工作已在进行中,以减少今后类似事件的可能性和影响.
自动翻译自官方事件更新。
我们正在调查一个影响Aura Console的问题,一些顾客可能无法看到他们的情况。 这个问题由Aura依赖的第三方服务失败所引起. 受影响的情况继续正常运行,数据库的连通性没有受到影响。 我们的小组正在积极调查这个问题.
我们正在继续调查这一问题.
奥拉依赖的第三方服务恢复了正常运行,而Neo4j Aura系统也恢复了. 我们的团队正在积极监测这个问题,以证实Aura Console正在按照预期进行.
经确认服务已开始运作,预计不会再中断.
# 发生的一切 # # What happened # Aura Console等Aura组件于协调世界时2026-07-10起于16:14相继中断,导致故障和坠机. 因此,一部分客户面临其案例的能见度问题。 它是由与Aura合并的外部第三方服务中断造成的. 关键是,数据库的连通性仍然不受限制,受影响的事件继续其正常运行。 为解决这一问题恢复了暗地服务 □ 服务是如何受到影响的 多个Aura组件,包括Aura Console,经历了中断. 用户在数据库相关网页和业务中遇到HTTP 500出错,尽管组织和项目仍然可以访问. 直接连接到特定数据库的情况完全没有受到影响 控制平面变得无法使用,这意味着用户无法通过API或Aura控制台创建,删除,调整大小,或调整实例设置. 然而,现有的事例仍在运作。 这个问题是由OutingDarkly的停电引起的,我们的服务在启动期间并没有优雅地处理这种依赖失败. 所有受影响的系统在协调世界时2026-07-1017:07恢复正常运作 ∮我们现在在做什么∮ Neo4j工程队迅速诊断出根源并恢复服役. 在评估这一事件时,我们确定了加快未来解决和减少再起风险的关键领域: * 分析关键事件衡量标准,侧重于警报至反应时间,以确定加快反应效率的机会 * 进行全面的回顾,强调成功结果,包括通过透明记录进行迅速的根由分析,通过事件管理工具进行无缝调整,以及使数据平面连接完好无损的多部分具有弹性和优雅的退化 * 积极开发更优雅的功能旗倒置默认,在供应商倒闭期间保护核心业务 * 通过整合先进的规划、混沌工程做法和生产层面的断层注射测试,加强建筑复原能力,以先发制人地发现并减缓潜在的故障路径 * 解决了操作者特征标记缓存的逻辑限制,强调操作者必须在当地储存被评价的旗帜,以便在外部依赖性失败时保持业务连续性.
自动翻译自官方事件更新。
运行 CREATE VECTOR INDEX 失败出错 51N31 错误: 系统配置或操作例外 - 不支持 。 在 V2026 02 中不支持使用提供的设置创建向量索引 。 运行所需版本为V2026 06. 请升级 DBMS.. 这只影响到新的指数,现有的VECTOR INDEX不受影响. 2026-06-30 09:00之前创建的任何向量指数继续正常运行.
我们现在正开始部署一个解决这一问题的办法,并将很快提供最新进展.
修复工作正在展开,进展顺利。 我们将介绍最新进展.
已向所有受影响的事例充分运用了这一方法。 这一事件现在已经得到解决.
# 发生的一切 # # What happened # 在2026-06-30 UTC08:00部署2026.06版本后,发现一个问题,在升级的Aura实例上运行"CREATE VECTOR INDEQ"引发了系统例外. 索引生成的这种失败发生是因为基础存储和内核需要额外的更新来支持操作 这一问题只影响到新的指数的制定;现有的矢量指数没有受到影响。 2026-06-30日09:00前创建的任何矢量指数都未受影响,继续正常工作. □ 服务是如何受到影响的 2026.06版本推出后,CREATE VECTOR INDEX语句的执行失败,影响了依赖新增向量索引的应用程序. 受影响的客户端收到错误 : 创建带有所提供设置的向量索引在 V2026\ 02 中不支持 。 运行所需的版本为V2026\ 06. 请升级 DBMS . 已存在的索引\(在此事件之前创建)和其他查询仍然完全未受影响并充分运作. ∮我们现在在做什么∮ Neo4j团队在Cypher计划中将根源确定为bug并用代码固定解决了这个问题. 已向所有受影响的奥拉事件应用了这一修复,以完全解决错误 为了防止今后发生这种情况,我们正在加强我们的监测和警报系统,以便在推出之前尽早发现类似问题,特别是在中转环境中。 同时,我们正在完善部署程序,以尽量减少客户的影响和恢复时间 此外,我们正在研究针对矢量指数生成等关键操作实施自动化升级后验证测试的备选方案
自动翻译自官方事件更新。
奥拉控制台正在经历一些间歇性错误:"我们的系统正在遇到问题. 如果问题继续存在,请稍后再次尝试或联系支持。" 这可能需要您重新装入或等待更长的时间在控制台进行导航 业务和Aura API没有受到影响 我们正在努力解决
我们正在继续调查解决这个问题的办法
我们正在继续努力解决这个问题。
我们正在部署一个变化。 我们将监测和更新.
继续监测已部署的变化。 下一次更新预计世界协调时上午10时6/24/2026.
我们检查并确认,这一问题现已得到全面解决.
这一事件已经得到解决.
# 发生的一切 # # What happened # 2026年1月22日 UTC中午12点左右,用户在Aura控制台内出现间歇性出错横幅显示,"我们遇到了问题. 再试一次...",这与控制台API端点的500个错误同时发生. 这些中断是短暂的,由TLS握手过程中的API内部出局时间所造成,一般在10秒左右或更新后解决 □ 服务是如何受到影响的 Aura Console和Aura API的性能退化了,表现为Aura控制台UI内的间歇性出错横幅. 一项调查确定,根源在于控制台内CPU使用率高和节流. API. 造成这一问题的主要原因是多次提出大型实体清单和要求核对员费用昂贵 为了解决这一问题,向Aura控制台和Aura API成功地部署了有针对性的解决办法。 随后调整了资源配置,以增加业务头室并确保稳定性 ∮我们现在在做什么∮ 为了减少发生类似事件的可能性,采取了下列反应性和主动性措施: * 开发一个监测仪表板,根据API内部日志数据观察请求的下降情况,以便在捕获问题发生之前进行自动监测和提醒 * 为减少高资源消耗和改善API稳定,在调和方请求之间错开时间 * 提高基础设施对资源的认识,以改进业绩 * 引入了基于服务级别查询的新过滤器,以优化调和器每次调用时的CPU管理费用 * 取消冗余请求中间软件处理,以优化API呼叫
自动翻译自官方事件更新。
Aura Console is currently not accessible. Our team is investigating the issue. Aura instances are running normally and are not impacted. They remain accessible via https://browser.neo4j.io/ and https://bloom.neo4j.io/ Console-related administration and configuration procedures may be unavailable. We will provide updates as soon as more information is available.
The Aura Console issue has now been resolved. The root cause was a failure while fetching public certificates from Auth0. We are reaching out to the Auth0 team to gather more detailed information about the incident.
This incident has been resolved.
**What Happened** During the incident window, users attempting to log in to the Aura Console were unable to do so. Auth0, the authentication provider for Aura Console, experienced an issue that prevented new authentication requests from completing. Existing sessions with valid cached tokens were largely unaffected. Aura database instances were running normally throughout and were not impacted, and access via the Aura API to database instances was also unaffected. **How the service was affected** Authentication requests from the Aura Console to Auth0 began failing, preventing new logins and session refreshes. Affected users received 503 errors when accessing the Aura Console. Once Auth0 recovered, access was restored. **What are we doing now** We've made two changes as a result of this incident: * Client identification: Authentication requests now include a clearer client identifier, reducing the chance of requests being incorrectly blocked in the future. * Observability: We've improved logging and alerting for authentication failures, including better visibility into errors from external services,so we can detect and escalate issues like this faster.
We identified an issue with the availability of console.neo4j.io - we are investigating
We have made a code change and we believe the console is available again.
We have checked and confirm that the issue is now fully addressed.
## What Happened On March 6, at 10:04 AM UTC, the Aura Console became inaccessible following a recent deployment. The deployment included changes related to user organizations and switching to an org memberships entity. This change caused the console to become inaccessible for a short period. ## How the service was affected A deployment to the Aura Console introduced an issue that caused an unexpected increase in backend requests related to access validation. This led to elevated CPU usage, which impacted the availability of the console and dependent services. We rolled back to a previous version to restore access. The rollback ensured the full restoration of access to the Aura Console, resolving the core issue within the incident window ## What are we doing now We are currently implementing a comprehensive strategy to bolster system resilience and prevent future recurrence. Our immediate actions include integrating stricter and more robust safeguards into the deployment pipeline. Crucially, we are significantly enhancing our validation processes to proactively detect and flag any potential performance impacts _before_ code is promoted to the production environment
A recent update resulted in MERGE queries which referenced the same merged property on both the left and right hand side of an ON MATCH SET or ON CREATE SET clause deleting that property from the node, or setting it to an invalid value during query runtime. The node being matched against must have had at least one property uniqueness constraint present. A fix has been identified and will be applied as soon as possible. Instances marked as "Production" are not impacted.
The fix is being deployed and the status page will be updated upon completion of the full deployment of the fix.
The fix is being deployed and the status page will be updated upon completion of the full deployment
The fix has now been deployed to those instances impacted and we are monitoring the situation.
The fix has been fully deployed to all impacted instances. This incident is now resolved.
## What Happened An issue was introduced in the Neo4j 2026.02 release where MERGE queries that referenced the same property on both the left and right sides of an `ON MATCH SET` or `ON CREATE SET` clause could potentially delete that property from the node or set it to an invalid value during query execution. This behaviour was observed specifically when the node being matched had at least one property uniqueness constraint. ## How the service was affected A change in the Neo4j 2026.02 release introduced a potential risk of writes failing or invalid data being returned for queries using MERGE together with `ON MATCH`. This issue affected instances across Aura tiers and required immediate investigation by Neo4j Engineering. The team identified the root cause and deployed a fix in version 2026.02.1. ## What are we doing now The following proactive measures have been implemented to reduce the likelihood of similar incidents: * We have strengthened test coverage for `ON CREATE` and `ON MATCH` clauses, particularly those involving more complex expressions. * We are investigating additional safeguards to improve our ability to control MergeInto/MergeUnique behaviour more flexibly, as well as potential rollback capabilities to support recovery in future incidents
We are aware of issues in the Middle East regions via our cloud partner AWS, affecting AWS me-central-1 (United Arab Emirates) and AWS me-south-1 (Bahrain). The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We are actively working to limit the impact on the Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels. Our team is available to advise and assist as needed.
We continue to monitor the situation in the affected AWS Middle East regions. The most up-to-date information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as soon as more information becomes available.
We continue to monitor the situation in the affected AWS Middle East regions. The latest information from AWS is available at: https://health.aws.amazon.com/health/status We will provide additional updates as more information becomes available. Please review the AWS recommendation on the website above.
While AWS continues working on this situation, we are closing this incident and invite our customers to monitor the AWS Status on our main Neo4j Status Page under AWS (Amazon Web Services). The latest information from AWS can be found at: https://health.aws.amazon.com/health/status
## What Happened On March 1, at 12:51 PM UTC, AWS services in the ME-CENTRAL-1 & ME-SOUTH-1 Region were impacted. Connectivity and power issues affected APIs and AWS core services essential to run Neo4j Aura prompting AWS to initiate an investigation ## How the service was affected Operations \(clone, backup, resuming/pausing, resizing\) that require additional resources like EC2 Instances, EBS Volumes, and other resources were impaired in the ME-CENTRAL-1 and ME-SOUTH-1 Region. Other AWS Services also experienced error rates and latencies for some workflows. Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure. A detailed summary of the AWS regional incident can be found here:[ https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status) ## What are we doing now We are actively working to limit the impact on the Neo4j Aura service. However, customers should expect that new deployments in the affected regions may be impaired. Additionally, existing services deployed in these regions may experience reduced availability. Customers with services in these or nearby regions who are concerned about potential operational impact are encouraged to contact Neo4j Customer Support through the usual channels Please visit AWS Status page for more info:[https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status)
我们找出了一个问题,它可能影响对AuraDB自由、专业和AuraDS的一组有限的Cypher 25查询。 这可能影响到: - 使用条件查询进行查询 -- -- When结合非分组汇总而不是无效值导致返回行数不正确。 - 使用 NEXT 查询可在某些情况下产生一个未定义的意外变量。 我们正积极制定解决办法,并将在获得更多信息后更新这一页.
我们已找到解决这个问题的办法,并将在奥拉展开。 一旦更新部署完毕,我们将更新这个塔特斯页面.
我们正在推出修复方案 完成后会给你更新.
解决办法已扩大到受影响的部分,我们现在正在监测局势.
我们目前继续监测局势.
已向所有受影响的事例充分运用了这一方法。 这一事件现在已经得到解决.
# # 发生的事情 # Neo4j于2026年1月26日07:49AM UTC开始将2026.01.1版本部署到Aura自由例. 在内部测试中检测出查询故障后,推出工作在达到Aura更高层次之前就被停止. 失败发生在规划者阶段之后的有条件查询\ (例如, 当... THEN...\) 中, 在聚合值大于无效值的情况下, 行为会有所不同 。 我们查明了根源,并制定了一项决议,并将其纳入第202.6.01.2版。 2026年1月27日,我们开始在奥拉各地部署2026.01.2,成功将所有受影响的环境升级为被修正的版本. □ 服务是如何受到影响的 在2026.01.1中使用When的查询,加上集合值大于无效值,返回的行数不正确。 使用 NEXT 查询在某些情况下可以产生一个未定义错误的出乎意料的变量. 这导致重写查询在聚合而非无效值的情况下表现不同. 附加条件的查询需要接收包含无效值的来行,并在不使用分组的情况下对数值进行聚合。 如果客户使用Cypher 25\(见[https://neo4j.com/docs/aura/managing-instances/cypher-version/](https://neo4j.com/docs/aura/managing-instances/cypher-version/))的有条件查询结构,结果就是错误的,这种影响仅限于有限的Aura实例。 ∮我们现在在做什么∮ 我们加强了检测程序,以确保全面覆盖所有产品领域。 这包括开发新的测试案例,旨在解决已查明的问题和潜在的未来情景。 此外,我们还将Cypher查询测试纳入到Aura内部,作为我们回归测试套件的标准组成部分。 这些检查现已成为我们持续一体化管道和中转环境中任何生产推出之前的强制性阶段.
自动翻译自官方事件更新。
Impact is that currently it is not possible to load data into GDS via native projection. Customers using Aura Graph Analytics are not impacted. We have identified a packaging issue with the latest release of Aura. Our engineering team is working on a fix.
Our teams have a fix and initiated the work to get it ready to roll-out. No current ETA available. We will keep you updated soon.
The fix is currently rolling out to production. We will update you upon completion
All instances should have the fix applied and if not it should be in the next 60 minutes
### **What happened** On January 15, 2026 at 22:12 UTC we began rolling out an update that included an incompatible version of a key component, affecting customers using the GDS plugin. This issue was reported on January 16 at 12:59 UTC, and a fix was deployed within hours, restoring functionality for the majority of affected users by 20:03 UTC. The issue occurred because Neo4’s packaging automation process selected the wrong version of the GDS component. GDS 2.25 should have been selected but instead GDS 2.24 was included in the bundle, which caused a compatibility issue. Although a corrected package was created and labeled separately, the release pipeline selected the incorrect package for deployment. This issue highlighted a gap in the release validation process, where incompatible component versions were not detected before rollout. ### **How customers were affected** Customers using the GDS plugin were unable to use any of the functionality the plugin provides during the incident window. The system configuration has been updated to ensure compatibility with the intended component versions, restoring full functionality. ### **What we are doing now** The following mitigations have been implemented: * Enhanced testing procedures to automatically verify compatibility between Neo4j and all bundled components before release. * Improved release processes to ensure that only explicitly validated and correctly labeled packages can be selected for deployment.
Neo4j opened a ticket with Azure and is awaiting updates on their resolution of the Azure Infrastructure issues. Impact on Neo4j Aura Services: Create, Resize (CPU and Storage), Pause, Resume.
Neo4j continues working with Microsoft via an Azure cloud ticket and is awaiting updates on their resolution of the Azure Infrastructure issues. Some resources have been made available, and impacted Neo4j Services have resumed operation. Customers have been notified. The Neo4j Aura Service is impacted when performing the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j operations, the operation will fail, and the Neo4j instance will become unavailable until Azure is able to provision additional resources.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance will become unavailable until Azure is able to provision additional resources.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Clone, Resume. As Azure resources become available when performing some Aura operations, the impacted instances may progressively recover and operations successfully complete. We continue to monitor progress, work with Microsoft Azure Infrastructure issues and will update.
We continue to work with our cloud infrastructure provider . Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.
We continue to work with our cloud infrastructure provider. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume.
We continue to work with Microsoft Azure. No expected improvements in addressing the issues around cloud resources in the affected regions before next week. Aura operations affected: Create, Resize (CPU and Storage), Pause, Clone, Resume. We will resume updates after this weekend or earlier if we have more information.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, effecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance may become unavailable or degraded until Azure is able to provision additional resources.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region, affecting the following operations: Create, Resize (CPU and Storage), Pause, Resume. If Azure resources are unavailable when requesting these types of Neo4j Aura operations, they will fail and the Neo4j Aura instance may become unavailable or degraded until Azure is able to provision additional resources.
The Neo4j Aura Service continues to be impacted by Azure Infrastructure issues in the US east region. We are working with our cloud partner and will resume updates once we have an ETA to share.
Cloud resources have become available in USEAST2 and we will monitor for a few hours to ensure there is no further customer impact.
Cloud resources have become available in USEAST2 and no further customer impact has been detected. This incident is resolved.
### **What Happened** Starting at 13:26 UTC on November 24th Microsoft Azure region eastus experienced a stock out situation, which impacted operations for all tiers of Neo4j Aura in that specific region. Additional capacity was requested straight away, but not until 17:06 UTC on December 10th did enough additional resources become available to resume all normal operations. **How the service was affected** All tiers within the Neo4j Aura Service were impacted when performing the following operations during this incident: Create, Resize \(CPU and Storage\), Clone, Pause and Resume. If Microsoft Azure resources were unavailable when requesting these types of Neo4j operations, the operation would fail, and the Neo4j instance would become unavailable until Azure was able to provision additional resources. ### **What are we doing now** To mitigate the scope of impact of future regional stock out issues, Neo4j is implementing the following measures: * Closely monitoring resource capacity to improve stockout predictions. * Regular calls with with our Cloud Service Provider to: * Learn about where regional resource capacity restrictions are forecast. * Plan for more resources in restricted regions. * Investigating other deployment models to allow us to keep Aura running in situations where 3 Availability Zones are not available.
We have identified an issue resulting in Pause, Resume and Delete operations to fail in both Console and Aura API across all tiers of Aura. We are actively working to resolve the issue and will report progress.
We have released a fix to this issue and are monitoring to ensure all operations are back to normal.
After monitoring the fix for some time, we can confirm that the issue is resolved and normal operations have resumed.
### What happened On November 18, 2025, some customers experienced issues with the delete, pause, and resume operations in the Console. These actions failed due to a temporary system issue introduced during a sequence of updates. While the updates were intended to improve functionality, they unintentionally reintroduced a previously resolved defect. The issue was identified quickly, and our teams acted immediately to restore normal operation. The root cause was a misconfiguration in the data processing module. An outdated schema caused the data parsing logic to misinterpret certain input parameters, leading to incorrect behavior and data display within the Console. We have since corrected the schema and added stricter validation to ensure compatibility moving forward. ### How customers were affected During the incident, some users experienced service disruptions when accessing the Console. Impacts included: * Intermittent connectivity issues * Inability to log in * Temporary unavailability of specific Console features No customer data was lost. To prevent a recurrence, we have improved our release process to ensure updates are deployed in the correct order, eliminating overlapping or out-of-sequence changes. ### What we are doing now Neo4j takes service reliability seriously and is strengthening safeguards to prevent similar incidents. New mitigations being deployed include: * Enhanced monitoring to detect related issues earlier * Additional automated checks to block faulty configurations before deployment * Improvements to overall service resilience to better tolerate similar failures We apologize for the disruption and appreciate our customers’ patience as we continue to harden our systems.
Many core operations for instances in AWS region us-east-1 are degraded as a result of AWS incident in that region: https://health.aws.amazon.com/health/status Core operations include create, pause, resume, clone, backup, among others. We continue to monitor the AWS incident and will provide updates accordingly.
We are continuing to monitor the AWS incident, and can report some slow improvement of impacted Aura instances in the AWS us-east1 region, though the service remains degraded in this region at this time. We are continuing to monitor progress in the AWS incident: https://health.aws.amazon.com/health/status
Instance operations in AWS us-east-1 region are back to normal following the resolution of the AWS incident. We will continue to monitor but all data indicates that the issue is fully resolved at this time.
### **What Happened** Between 08:41 UTC on October 20th and 09:00 UTC on October 21st, Neo4j Aura experienced service disruptions affecting the us-east-1 \(N. Virginia\) region in AWS. The incident was triggered by a broad AWS regional outage impacting Identity and Access Management \(IAM\) and the EC2 control plane. This resulted in delayed backups, temporary loss of database fault tolerance for a subset of users, and internal delays in administrative actions due to toolchain failures. A detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/) ### **How the service was affected** The primary cause was several AWS regional service disruptions in us-east-1. We will cover how each of these affected Neo4j Aura and its users. Neo4j Aura is designed to isolate regional failures. This is achieved through deploying customer instances in Orchestras that have instances in three availability zones and no cross region dependencies. AWS IAM and Identity Center became unresponsive, preventing Neo4j Aura’s automated systems from authenticating with AWS resources in us-east-1. This affected Neo4j Aura backups to be written to AWS S3 buckets. Customers were also not able to resume paused instances during this period as the resume process was not able to authenticate with AWS S3 buckets to retrieve the paused data set. Neo4j Aura’s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. AWS Network Load Balancer health check system failures and AWS EC2 “request limit exceeded” or “insufficient capacity” errors in us-east-1 were false negatives with the NLB heath checks which resulted in some Neo4j Aura DB clusters in us-east-1 losing fault tolerance \(1 out of 3 cluster members unavailable\). When this happened instances were removed by kubernetes and we were not able to provision new ones due to the EC2 failures noted earlier, leaving the clusters without fault tolerance for a prolonged period of time. All of these clusters still had full availability of the other two cluster members. ### **What are we doing now** Largely Neo4j Aura responded as designed to these events, isolating failures to us-east-1, with no to minimal cross system failure propagation. The cross cloud impact of creating DNS records for new instances was the main outlier. To mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures: * Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies. * Remove identified cross-region dependencies.
An active issue on AWS us-east-1 is affecting Neo4j Aura operations in the regions where we have some dependency on an impacted AWS service. See more details https://health.aws.amazon.com/health/status Other regions not currently impacted.
Operations such as Create, Pause, Resume, Clone are affected globally due to a dependency. Backups in the affected region of AWS us-est-1 will be impacted The affected AWS service is now starting to recover and we are monitoring the situation
We see clear signs of recovery and our impacted service are progressively getting back to normal. We will monitor and update when we can confirm full recovery and normal operations.
We are continuing to see good recovery across the service. We will update when this is completed.
The underlying AWS incident has bene resolved and our services have now resumed and fully recovered
### **What Happened** Between 08:41 UTC on October 20th and 09:00 UTC on October 21st, Neo4j Aura experienced service disruptions affecting the us-east-1 \(N. Virginia\) region in AWS. The incident was triggered by a broad AWS regional outage impacting Identity and Access Management \(IAM\) and the EC2 control plane. This resulted in delayed backups, temporary loss of database fault tolerance for a subset of users, and internal delays in administrative actions due to toolchain failures. A detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/) ### **How the service was affected** The primary cause was several AWS regional service disruptions in us-east-1. We will cover how each of these affected Neo4j Aura and its users. Neo4j Aura is designed to isolate regional failures. This is achieved through deploying customer instances in Orchestras that have instances in three availability zones and no cross region dependencies. AWS IAM and Identity Center became unresponsive, preventing Neo4j Aura’s automated systems from authenticating with AWS resources in us-east-1. This affected Neo4j Aura backups to be written to AWS S3 buckets. Customers were also not able to resume paused instances during this period as the resume process was not able to authenticate with AWS S3 buckets to retrieve the paused data set. Neo4j Aura’s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. AWS Network Load Balancer health check system failures and AWS EC2 “request limit exceeded” or “insufficient capacity” errors in us-east-1 were false negatives with the NLB heath checks which resulted in some Neo4j Aura DB clusters in us-east-1 losing fault tolerance \(1 out of 3 cluster members unavailable\). When this happened instances were removed by kubernetes and we were not able to provision new ones due to the EC2 failures noted earlier, leaving the clusters without fault tolerance for a prolonged period of time. All of these clusters still had full availability of the other two cluster members. ### **What are we doing now** Largely Neo4j Aura responded as designed to these events, isolating failures to us-east-1, with no to minimal cross system failure propagation. The cross cloud impact of creating DNS records for new instances was the main outlier. To mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures: * Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies. * Remove identified cross-region dependencies.
We are currently investigating this issue.
We are aware of an issue that could result in a degradation in write performance for all Aura instance. We have identified the cause and are preparing a fix.
We are continuing to investigate this issue.
The issue impact has been refined and currently could impact AuraDB Virtual Dedicated Cloud and Business Critical instances only. We have identified the cause and the faulty component has been reverted for the majority of instances. We will continue to monitor the situation, while the full fix is prepared.
We continue to work towards the issue resolution.
We are continuing to investigate this issue.
We are continuing to monitor the situation whilst a full fix for the solution is prepared.
We are continuing to monitor the situation. The full fix for the solution is currently undergoing final testing and will start deployment once testing is completed.
The full fix for the solution is starting to be deployed across the estate and are continuing to monitor the situation.
We are continuing to monitor for any further issues.
The full fix for the solution is continuing to be deployed across the estate and are continuing to monitor the situation.
The full fix for the solution has now been deployed across the estate and this issue is now resolved.
### **What happened** Between August 22 and August 28, 2025, a performance issue affected some of our database services following a recent update. Our team quickly responded and discovered that the problem was due to a bug in the latest update, which caused certain memory settings to be incorrectly configured. We promptly applied the previous version of those settings to stabilize the affected databases. By August 28, all databases were successfully transferred to a new, stable version, and the incident was fully resolved. The issue was caused by a misconfiguration in the system's data processing module. Specifically, an incorrect parameter setting in the data pipeline led to a bottleneck, which slowed down the processing speed. This misconfiguration affected the way data was being queued and processed, resulting in delays. Our technical team has identified the root cause and implemented a fix to ensure that the data pipeline operates efficiently, preventing future occurrences of this issue. ### **How the service was affected** Some customers reported a performance change on their instance. ### **What we are doing now** Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. New mitigations being deployed: * Enhancing our monitoring systems to detect similar issues faster * Implementing additional automated checks to prevent service disruptions * Improving our service resilience to handle similar scenarios * Introducing dynamic configuration management to ensure seamless updates * Enabling multiple configuration defaults to better manage database priorities * Improving notification systems for faster response to potential issues * Enhancing our tools to streamline database management and transfers
Engineers are investigating an issue whereby instance actions are not working. You may be unable to import data, pause, resume, create, delete or run manual backups for your instances. Regular Neo4j scheduled backups are continuing to run as normal. You may be unable to see your instances in the Aura Console. CMI is also experiencing an outage, you may be unable to ingest metrics from your Aura instances.
A fix has been identified and implemented. Instances should be showing on the console and instance operations should now be available. You should now also be able to ingest metrics using CMI. We are continuing to monitor the status of these services.
This incident has been resolved.
### What happened On August 22, 2025, from 10:10 to 11:27 UTC, users experienced an issue with the Aura Console where instance operations were unavailable. This was due to a timing issue with refreshing security keys that affected the visibility and operations of instances in the Aura Console and also caused an outage in the Customer Metrics Integration \(CMI\) and Aura API. The issue was identified within 5 minutes and efforts to resolve it began promptly. The problem was traced back to a recent update and issues with authentication were resolved by refreshing the system cache, with the service fully restored by 11:27 UTC. The issue arose because of a timing mismatch between the creation of new security keys and their recognition by our system. When new keys were generated, they were quickly used by the Console API. However, another part of our system, the database manager, was still using an older set of keys to verify requests. This mismatch caused requests to fail because the database manager could not recognize the new keys. No unauthorized operations were allowed and this did not affect the security of the service in any way. After approximately an hour, the system automatically updated its keys, and everything started working correctly again. ### How customers were affected Aura Console features were impacted, including the visibility of instances and therefore ability to connect to instances through the console. Driver connections to instances were not impacted. The issue also impacted the use of parts of the service including Customer Metrics Integration \(CMI\) and the Aura API. ### What we are doing now Neo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future. We are taking steps to prevent similar issues in the future by improving our processes and monitoring systems. Changes we are making: * Enhancing our caching mechanisms to ensure seamless updates and prevent similar issues in the future. * Designing a robust process for updating service accounts and keys to guarantee uninterrupted service reliability.