{
"vendor": "Neo4j Aura",
"slug": "neo4j-aura",
"platform": "statuspage",
"status_url": "https://status.neo4j.io",
"last_checked": "2026-09-16T12:28:20Z",
"last_state": "degraded",
"history_backfilled": true,
"first_watched": "2026-09-04T07:06:16Z",
"incidents": [
{
"body": "A fix is being rolled out and the portal should become less impacted by errors over time. See details https://status.salesforce.com/incidents/20004433",
"first_seen": "2026-09-16T12:28:20Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"started_at": "2026-09-16T08:50:58.001Z",
"state": "monitoring",
"title": "Customer support portal issues",
"updated_at": "2026-09-16T11:30:43.862Z",
"url": "https://stspg.io/7n7b4bm9wbjm"
},
{
"body": "All affected components are now fully recovered.",
"first_seen": "2026-09-10T12:15:40Z",
"impact": "critical",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-09-09T13:39:53.099Z",
"resolved_inferred": false,
"started_at": "2026-09-09T12:31:50.233Z",
"state": "resolved",
"title": "Console and API outage",
"updated_at": "2026-09-09T13:39:53.126Z",
"url": "https://stspg.io/x8rccw2ck809"
},
{
"body": "All instances are available, manual steps to unblock the remaining small number of instances was undertaken to resolve.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-09-04T15:36:12.055Z",
"resolved_inferred": false,
"started_at": "2026-09-03T16:43:28.850Z",
"state": "resolved",
"title": "A small number of Free Tier instances are experiencing issues updating",
"updated_at": "2026-09-04T15:36:12.073Z",
"url": "https://stspg.io/txy1c92n0b9m"
},
{
"body": "Since the last update, the investigation has moved on. The issue was identified, and we monitored the service as it recovered from degradation. We confirm the issue is now resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-20T19:10:58.194Z",
"resolved_inferred": false,
"started_at": "2026-08-20T15:49:37.023Z",
"state": "resolved",
"title": "Aura metrics issue.",
"updated_at": "2026-08-20T19:10:58.209Z",
"url": "https://stspg.io/n4gtks67r6gp"
},
{
"body": "We have monitored the fix and found the service to be stable. This incident is now considered resolved.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-08-07T15:34:37.846Z",
"resolved_inferred": false,
"started_at": "2026-08-05T17:31:11.727Z",
"state": "resolved",
"title": "Potential unexpected query failures.",
"updated_at": "2026-08-07T15:34:37.862Z",
"url": "https://stspg.io/fjp0c9ctq1bx"
},
{
"body": "### **What happened**\n\nOn Thursday, Jul 23, 2026 10:33 UTC a configuration change was deployed to Aura that unintentionally altered how memory allocations were calculated for database instances. As a result, a subset of instances received insufficient memory, causing some database instances to become unavailable or unable to complete updates.\n\nThe adjusted memory allocation led to out-of-memory conditions, causing database instances to repeatedly restart due to insufficient memory resources or become stuck updating. This issue affected instances across multiple cloud providers and multiple product tiers.\n\nOnce the issue was identified, we immediately reverted the configuration change, preventing any additional instances from receiving the incorrect configuration. A corrected configuration was deployed to production by Thursday, Jul 23, 2026 11:56 UTC. However, database instances that had already received the incorrect configuration required individual recovery actions before they could return to normal operation.\n\nBy Thursday Jul 23, 2026 17:59 UTC, all known customer-impacting database instances had been recovered. Monitoring continued through the following day, with the incident fully resolved on Friday, Jul 24, 2026 16:30 UTC.\n\n### **How the service was affected**\n\nThe primary customer impact was that several AuraDB database instances became unavailable or entered a degraded state. Affected instances were unable to complete routine software updates and, in some cases, repeatedly restarted because insufficient memory had been allocated.\n\n* **Service availability:** Customer impact varied by service tier. AuraDB Professional instances, which do not provide High Availability, experienced the greatest level of service disruption, with a subset becoming unavailable and unable to process reads or writes. For affected AuraDB Business Critical and Virtual Dedicated Cloud \\(VDC\\) instances, the impact was generally limited to a temporary loss of fault tolerance while service availability was maintained. In a smaller number of cases, Business Critical and VDC instances also became unavailable.\n* **Stuck updates**: Additional instances remained available but were stuck in an \"Updating\" state, which blocked customer-initiated operations such as resizes or configuration changes.\n* **Cross-platform scope**: The impact spanned all three supported cloud providers and multiple regions, affecting customers globally.\n\nCustomer Support cases were raised and our team triaged and manually recovered affected instances in priority order. The majority of AuraDB instances continued to operate normally. Customer impact was fully mitigated through the configuration revert and targeted manual recovery of each affected instance.\n\n### **What we are doing now**\n\nWe have carried out a thorough analysis of this incident and have identified the following actions:\n\n* **Prevention**\n\n    * **Improved deployment validation:** We are strengthening our release validation process to better identify configuration changes.\n    * **Component decoupling**: We are evaluating improvements to the sequencing of component deployments to reduce the risk of unintended changes being included in releases.\n    * **Progressive rollout strategy**: We are reviewing the rollout process for the affected components, to bring them in line with the rollout controls used for other critical components.\n    \n\n* **Detection**\n\n    * **Better alerting**: We are enhancing our monitoring to detect abnormal increases in failure rates \\(such as loss of fault tolerance or availability\\) more quickly and reliably.\n    \n* **Mitigation**\n\n    * **Safer configuration deployment:** We are improving how production configuration changes are deployed so they can be disabled or rolled back more quickly without requiring a broader software release.\n    * **Faster manual recovery tooling**: We are improving our recovery tooling to reduce the time required to identify and manually recover affected instances.\n    \n\nWe recognize the disruption this incident caused and apologize for the impact to affected customers. We have completed the immediate corrective actions, and the longer-term improvements described above are already underway to reduce the likelihood and impact of similar incidents in the future.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-24T15:56:10.125Z",
"resolved_inferred": false,
"started_at": "2026-07-23T10:52:38.439Z",
"state": "postmortem",
"title": "Issue impacting Aura instance operations",
"updated_at": "2026-07-29T21:59:17.837Z",
"url": "https://stspg.io/f0r2mj7qz9cx"
},
{
"body": "## What Happened\n\nAura Console and other Aura components experienced disruptions on 2026-07-10 at 16:14 UTC, resulting in failures and crashloops. Consequently, a segment of customers faced visibility issues regarding their instances. It was caused by an outage in an external third-party service integrated with Aura. Crucially, database connectivity remained uncompromised, and the impacted instances continued their normal operations. LaunchDarkly service was restored to resolve the issue\n\n## How the service was affected\n\nMultiple Aura components, including the Aura Console, experienced disruptions. Users encountered HTTP 500 errors on database-related pages and operations, though organizations and projects could still be accessed. Direct connections to specific database instances were completely unaffected\n\nThe control plane became unavailable, which meant that users could not create, delete, resize, or adjust settings for instances via the API or the Aura console. Existing instances, however, remained operational. The issue was caused by an outage on LaunchDarkly and our services did not handle that dependency failure gracefully during startup. All affected systems returned to normal operation by\u00a0 2026-07-10 at 17:07 UTC\n\n## What are we doing now\n\nThe Neo4j Engineering team swiftly diagnosed the root cause and restored service. In evaluating this incident, we have identified key areas to accelerate future resolutions and mitigate recurrence risks:\n\n* Analyzed key incident metrics, focusing on alert-to-response duration to identify opportunities for accelerating response efficiency\n* Conducted a comprehensive retrospective highlighting successful outcomes, including swift root-cause analysis via transparent logging, seamless alignment via the incident management tool, and the resilient, graceful degradation of multiple components that kept data plane connectivity intact\n* Actively developing more graceful fallback defaults for feature flags to safeguard core operations during vendor downtimes\n* Strengthening architectural resilience by integrating advanced planning, chaos engineering practices, and production-level fault injection testing to preemptively uncover and mitigate potential failure paths\n* Addressed logic limitations in operator feature flag caching, emphasizing the necessity for operators to store evaluated flags locally to preserve operational continuity if external dependencies fail.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-07-10T19:23:29.899Z",
"resolved_inferred": false,
"started_at": "2026-07-10T17:18:26.938Z",
"state": "postmortem",
"title": "Aura Console Impacted - Instance View",
"updated_at": "2026-07-27T04:29:06.099Z",
"url": "https://stspg.io/fwjj9tdqq78k"
},
{
"body": "## What Happened\n\nAn issue was identified following the deployment of version 2026.06 on 2026-06-30 at 08:00 UTC, where running `CREATE VECTOR INDEX` on upgraded Aura instances triggered a system exception. This failure in index generation occurred because the underlying store and kernel required additional updates to support the operation\n\nThis problem only impacted the creation of new indexes; existing vector indexes are not affected. Any vector index created before 09:00 on 2026-06-30 was unaffected and continued to work normally.\u00a0\n\n## How the service was affected\n\nFollowing the rollout of version 2026.06, execution of the CREATE VECTOR INDEX statement failed, impacting applications that depended on adding new vector indexes. Affected clients received the error: _Creating a vector index with provided settings is not supported in V2026\\_02. The required version for operation is V2026\\_06. Please upgrade DBMS_. Existing indexes \\(created prior to this incident\\) and other queries remained entirely unaffected and fully functional.\n\n## What are we doing now\n\nNeo4j teams identified the root cause as a bug in the Cypher planner and resolved the issue with a code fix. This fix has been deployed to all affected Aura instances, fully resolving the error\n\nTo prevent future occurrences, we are enhancing our monitoring and alerting systems to detect similar issues earlier, particularly within staging environments, before rollouts occur. Simultaneously, we are refining our deployment processes to minimize customer impact and recovery times\n\nAdditionally, we are investigating options to implement automated, post-upgrade validation tests specifically for critical operations such as vector index creation",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-30T17:45:08.397Z",
"resolved_inferred": false,
"started_at": "2026-06-30T14:45:56.593Z",
"state": "postmortem",
"title": "AuraDB issue: Errors when running CREATE VECTOR INDEX",
"updated_at": "2026-07-20T08:40:37.284Z",
"url": "https://stspg.io/bfw41pvqwk7j"
},
{
"body": "## What Happened\n\nAt approximately 12:00 UTC on January 22, 2026, users encountered intermittent error banners within the Aura console displaying, \"We're having a problem. Try again.,\" which occurred alongside 500 errors from console API endpoints. These disruptions were transient and caused by internal API timing out during the TLS handshake process, typically resolving within about 10 seconds or following a page refresh\n\n## How the service was affected\n\nThe Aura Console and Aura API experienced degraded performance, which manifested as intermittent error banners within the Aura console UI. An investigation identified the root cause as high CPU usage and throttling within the console API. This issue was primarily driven by repeated large entity listings and expensive reconciler requests\n\nTo address the issue, targeted fixes were successfully deployed to both the Aura console and Aura API. This was followed by adjustments to the resource configuration to increase operational headroom and ensure stability\n\n## What are we doing now\n\nThe following reactive and proactive measures have been implemented to reduce the likelihood of similar incidents:\n\n* Developed a monitoring dashboard to observe request drops based on internal API log data to implement automated monitoring and alerting to catch issues before they occur\n* Implemented a staggered delay between paginated reconciler requests to mitigate high resource consumption and improve API stability\n* Enhanced infrastructure aware resources calculations to improve performance\n* Introduced a new filter for queries based on service tiers to optimize CPU overhead for each calls performed by the reconciler\n* Deactivated redundant request middleware processing to optimize API calls",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-06-24T09:14:35.823Z",
"resolved_inferred": false,
"started_at": "2026-06-23T11:25:47.835Z",
"state": "postmortem",
"title": "Aura console experiencing some intermittent errors",
"updated_at": "2026-07-10T14:50:29.848Z",
"url": "https://stspg.io/7tqbvt3xkd3r"
},
{
"body": "**What Happened**\n\nDuring 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.\n\n**How the service was affected**\n\nAuthentication 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.\n\n**What are we doing now**\n\nWe've made two changes as a result of this incident:\n\n* Client identification: Authentication requests now include a clearer client identifier, reducing the chance of requests being incorrectly blocked in the future.\n* 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.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-05-26T23:06:47.524Z",
"resolved_inferred": false,
"started_at": "2026-05-26T18:23:22.000Z",
"state": "postmortem",
"title": "Aura Console Auth error",
"updated_at": "2026-06-12T16:20:48.205Z",
"url": "https://stspg.io/1zcc4tqqzskm"
},
{
"body": "## What Happened\n\nOn March 6, at 10:04 AM UTC,\u00a0 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.\n\n## How the service was affected\n\nA 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\n\n## What are we doing now\n\nWe 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",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "critical",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-06T10:25:16.780Z",
"resolved_inferred": false,
"started_at": "2026-03-06T10:18:56.497Z",
"state": "postmortem",
"title": "Console is not available",
"updated_at": "2026-04-02T06:48:17.165Z",
"url": "https://stspg.io/0l3qwfsg49bw"
},
{
"body": "## What Happened\n\nAn 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.\n\nThis behaviour was observed specifically when the node being matched had at least one property uniqueness constraint.\n\n## How the service was affected\n\nA 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`.\n\nThis 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.\n\n## What are we doing now\n\nThe following proactive measures have been implemented to reduce the likelihood of similar incidents:\n\n* We have strengthened test coverage for `ON CREATE` and `ON MATCH` clauses, particularly those involving more complex expressions.\n* 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",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "none",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-04T15:19:45.351Z",
"resolved_inferred": false,
"started_at": "2026-03-03T21:35:35.749Z",
"state": "postmortem",
"title": "Subset of MERGE queries lead to setting unexpected property values",
"updated_at": "2026-04-08T06:39:22.446Z",
"url": "https://stspg.io/5dk93c72kc2t"
},
{
"body": "## What Happened\n\nOn 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\n\n## How the service was affected\n\nOperations \\(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)\n\n## What are we doing now\n\nWe 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\n\nPlease visit AWS Status page for more info:[https://health.aws.amazon.com/health/status](https://health.aws.amazon.com/health/status)",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-03-06T16:06:45.872Z",
"resolved_inferred": false,
"started_at": "2026-03-02T19:55:47.600Z",
"state": "postmortem",
"title": "Middle East Availability - AWS",
"updated_at": "2026-04-02T06:37:32.508Z",
"url": "https://stspg.io/0dz8yw87bs1z"
},
{
"body": "## **What Happened**\n\nNeo4j commenced the deployment of version 2026.01.1 to Aura free instances at 07:49 AM UTC on January 26, 2026. Following the detection of query failures during internal testing, the rollout was halted before it reached Aura higher tiers.\u00a0\n\nThe failures occurred on conditional queries \\(e.g. WHEN \u2026THEN \u2026\\) after the planner phase to behave differently in the case of aggregation over null values.\n\nWe identified the root cause and developed a resolution, which was integrated into version 2026.01.2. On January 27, 2026, we began deploying 2026.01.2 across Aura instances, successfully upgrading all affected environments to the corrected version\n\n## How the service was affected\n\nQueries using WHEN in 2026.01.1 in combination with aggregation over null values get an incorrect number of rows returned. Queries using NEXT can in some instances produce an unexpected variable not defined error. This caused the rewritten query to behave differently in the case of aggregation over null values.\u00a0\n\nThe conditional query would need to receive incoming rows containing null values and be aggregating over the values without using a grouping. Customers received an incorrect result if they were using the conditional query construct in Cypher 25 \\(see [https://neo4j.com/docs/aura/managing-instances/cypher-version/](https://neo4j.com/docs/aura/managing-instances/cypher-version/)\\), an impact that was limited to a limited number of Aura instances.\u00a0\n\n## What are we doing now\n\nWe have enhanced our testing procedures to ensure comprehensive coverage across all product areas. This includes the development of new test cases designed to address both identified issues and potential future scenarios.\u00a0\n\nFurthermore, we have integrated Cypher query testing within Aura as a standard component of our regression testing suite. These checks are now mandatory stages within our Continuous Integration pipeline and staging environments prior to any production rollout.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-01-27T15:58:17.228Z",
"resolved_inferred": false,
"started_at": "2026-01-26T19:26:32.605Z",
"state": "postmortem",
"title": "Limited set of queries impacted by Cypher 25 issue",
"updated_at": "2026-07-02T04:22:23.497Z",
"url": "https://stspg.io/s3qllcm4gv6g"
},
{
"body": "### **What happened**\n\nOn 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.\u00a0\n\nThe issue occurred because Neo4\u2019s 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.\u00a0\n\nThis issue highlighted a gap in the release validation process, where incompatible component versions were not detected before rollout.\n\n### **How customers were affected**\n\nCustomers using the GDS plugin were unable to use any of the functionality the plugin provides during the incident window.\u00a0\n\nThe system configuration has been updated to ensure compatibility with the intended component versions, restoring full functionality.\n\n### **What we are doing now**\n\nThe following mitigations have been implemented:\u00a0\n\n* Enhanced testing procedures to automatically verify compatibility between Neo4j and all bundled components before release.\n* Improved release processes to ensure that only explicitly validated and correctly labeled packages can be selected for deployment.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2026-01-16T19:36:41.109Z",
"resolved_inferred": false,
"started_at": "2026-01-16T14:25:56.963Z",
"state": "postmortem",
"title": "Data science feature on AuraDS , AuraDSE and Aura Professional tiers - Native projection affected.",
"updated_at": "2026-04-23T13:27:24.149Z",
"url": "https://stspg.io/pzcv6h9c57cw"
},
{
"body": "### **What Happened**\n\nStarting 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.\n\n**How the service was affected**\n\nAll 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.\u00a0\n\n### **What are we doing now**\n\nTo mitigate the scope of impact of future regional stock out issues, Neo4j is implementing the following measures:\n\n* Closely monitoring resource capacity to improve stockout predictions.\n* Regular calls with with our Cloud Service Provider to:\n\n    * Learn about where regional resource capacity restrictions are forecast.\n    * Plan for more resources in restricted regions.\n    \n* Investigating other deployment models to allow us to keep Aura running in situations where 3 Availability Zones are not available.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-12-11T15:39:59.138Z",
"resolved_inferred": false,
"started_at": "2025-11-26T15:47:58.305Z",
"state": "postmortem",
"title": "Neo4j Aura Service impacted by Resource Shortage in Azure US East",
"updated_at": "2026-02-04T15:18:31.183Z",
"url": "https://stspg.io/z76b3z3k80h2"
},
{
"body": "### What happened\n\nOn 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.\n\nThe issue was identified quickly, and our teams acted immediately to restore normal operation.\n\nThe 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.\n\n### How customers were affected\n\nDuring the incident, some users experienced service disruptions when accessing the Console. Impacts included:\n\n* Intermittent connectivity issues\n* Inability to log in\n* Temporary unavailability of specific Console features\n\nNo customer data was lost.\n\nTo 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.\n\n### What we are doing now\n\nNeo4j takes service reliability seriously and is strengthening safeguards to prevent similar incidents.\n\nNew mitigations being deployed include:\n\n* Enhanced monitoring to detect related issues earlier\n* Additional automated checks to block faulty configurations before deployment\n* Improvements to overall service resilience to better tolerate similar failures\n\nWe apologize for the disruption and appreciate our customers\u2019 patience as we continue to harden our systems.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-11-18T16:39:05.842Z",
"resolved_inferred": false,
"started_at": "2025-11-18T15:56:12.929Z",
"state": "postmortem",
"title": "Pause / Resume / Destroy operations failing",
"updated_at": "2026-01-14T14:05:50.571Z",
"url": "https://stspg.io/2bnk6pt9m3sr"
},
{
"body": "### **What Happened**\n\nBetween 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.\n\nA detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/)\n\n### **How the service was affected**\n\nThe 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.\n\nAWS IAM and Identity Center became unresponsive, preventing Neo4j Aura\u2019s 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\u2019s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. \n\nAWS Network Load Balancer health check system failures and AWS EC2 \u201crequest limit exceeded\u201d or \u201cinsufficient capacity\u201d 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.\n\n### **What are we doing now**\n\nLargely 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.\u00a0\n\nTo mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures:\n\n* Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies.\u00a0\n* Remove identified cross-region dependencies.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-10-20T21:28:16.782Z",
"resolved_inferred": false,
"started_at": "2025-10-20T16:43:35.114Z",
"state": "postmortem",
"title": "Several operations degraded for AWS instances in region us-east-1",
"updated_at": "2026-01-15T17:49:09.512Z",
"url": "https://stspg.io/8h32s5wy2r5f"
},
{
"body": "### **What Happened**\n\nBetween 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.\n\nA detailed summary of the AWS regional incident can be found here: [https://aws.amazon.com/message/101925/](https://aws.amazon.com/message/101925/)\n\n### **How the service was affected**\n\nThe 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.\n\nAWS IAM and Identity Center became unresponsive, preventing Neo4j Aura\u2019s 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\u2019s inability to authenticate with Route53 to create new DNS entries affected Neo4j Aura DB creation, as new databases were created. \n\nAWS Network Load Balancer health check system failures and AWS EC2 \u201crequest limit exceeded\u201d or \u201cinsufficient capacity\u201d 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.  \n\n### **What are we doing now**\n\nLargely 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.\u00a0\n\nTo mitigate the scope of impact of future regional outages, Neo4j is implementing the following measures:\n\n* Full Neo4j Aura reviews to ensure Neo4j Aura design is implemented as intended across all sub-systems to surface any cross region dependencies.\u00a0\n* Remove identified cross-region dependencies.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-10-20T11:13:18.893Z",
"resolved_inferred": false,
"started_at": "2025-10-20T09:15:00.047Z",
"state": "postmortem",
"title": "Aura operations on AWS affected by an incident in US-EAST-1 region",
"updated_at": "2026-01-15T17:34:41.334Z",
"url": "https://stspg.io/cclgmkdlytyw"
},
{
"body": "### **What happened**\n\nBetween 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.\n\nThe 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.\n\n### **How the service was affected**\n\nSome customers reported a performance change on their instance.\u00a0\n\n### **What we are doing now**\n\nNeo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future.\n\nNew mitigations being deployed:\n\n* Enhancing our monitoring systems to detect similar issues faster\n* Implementing additional automated checks to prevent service disruptions\n* Improving our service resilience to handle similar scenarios\n* Introducing dynamic configuration management to ensure seamless updates\n* Enabling multiple configuration defaults to better manage database priorities\n* Improving notification systems for faster response to potential issues\n* Enhancing our tools to streamline database management and transfers",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-08-27T16:46:22.351Z",
"resolved_inferred": false,
"started_at": "2025-08-25T13:34:19.372Z",
"state": "postmortem",
"title": "Database instance write performance impacted",
"updated_at": "2025-10-06T13:32:44.058Z",
"url": "https://stspg.io/qkm18s0mrzw7"
},
{
"body": "### What happened\n\nOn 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.\u00a0\n\nThe 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.\n\n### How customers were affected\n\nAura 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.\n\nThe issue also impacted the use of parts of the service including Customer Metrics Integration \\(CMI\\) and the Aura API.\n\n### What we are doing now\n\nNeo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future.\n\nWe are taking steps to prevent similar issues in the future by improving our processes and monitoring systems.\n\nChanges we are making:\n\n* Enhancing our caching mechanisms to ensure seamless updates and prevent similar issues in the future.\n* Designing a robust process for updating service accounts and keys to guarantee uninterrupted service reliability.",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "major",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-08-22T13:31:58.613Z",
"resolved_inferred": false,
"started_at": "2025-08-22T11:02:01.538Z",
"state": "postmortem",
"title": "CMI & Instance Operations Unavailable",
"updated_at": "2025-09-12T15:45:59.688Z",
"url": "https://stspg.io/c7v46ysln3zn"
},
{
"body": "### What happened\n\nOn August 18, 2025, at 19:18 UTC, the release of a faulty component in Neo4j Aura impacted the ability to perform backups of customer instances. The problem was identified when a critical component was updated without aligning with another dependent component, leading to failed backup attempts. This resulted in Neo4j not being able to take backups of customer instances for a period of approximately 17 hours. Our team quickly identified the root cause and began mitigation efforts early on August 19, 2025. By 11:54 UTC, the issue was fully resolved, and normal backup operations resumed. We apologize for any inconvenience this may have caused and are taking steps to prevent similar issues in the future.\n\nThe issue arose because the deployment of the neo4j-backup system was not properly synchronized with the deployment of the neo4j-operator. This misalignment led to critical changes being introduced that impacted the ability to create new backups effectively. Essentially, the two components were not updated in harmony, which caused disruptions in the backup process.\n\n### How customers were affected\n\nCustomers were unable to\u00a0 get successful backups of their instances for 17 hours. We promptly addressed the issue by reverting the recent backup changes that caused disruptions and ensured the stability of our service by cleaning up old, failing backups.\n\n### What we are doing now\n\nNeo4j remains committed to providing reliable service and is implementing additional safeguards to prevent similar incidents in the future.\n\nNew mitigations being deployed:\n\n* Enhancing our monitoring systems to detect similar issues faster\n* Implementing additional automated checks to prevent service disruptions\n* Improving our service resilience to handle similar scenarios",
"first_seen": "2026-09-04T07:06:16Z",
"impact": "minor",
"last_seen": "2026-09-16T12:28:20Z",
"resolved_at": "2025-08-19T12:04:18.329Z",
"resolved_inferred": false,
"started_at": "2025-08-19T09:19:36.177Z",
"state": "postmortem",
"title": "Some issues with backups",
"updated_at": "2025-09-12T19:42:06.338Z",
"url": "https://stspg.io/vztz2h95h13r"
}
]
}