Is Neo4j Aura down?

We are currently aware of an issue that is impacting customers using Aura on Azure, when attempting to download database instance snapshots.

We have identified the issue and are currently working on the deployment of the fix.

The fix is currently being tested in lower environments, prior to being deployed.

Testing of the fix is ongoing and deployment will proceed once the testing has been completed.

Our engineers have successfully deployed a fix, and the issue is now resolved. Aura customers on Azure can now download database snapshots without issues.

We are currently investigating an issue affecting the Europe West 2 region in GCP which is causing databases to become unavailable.

We are continuing to investigate the issue currently, working with the GCP to find a resolution. At this time some operations, including database instance creation in the region continue to remain impacted.

We have identified the source of the issue currently affecting customers on europe-west2 on GCP. Further details available from GCP statuspage at https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj. At this time some operations, including database instance creation in the region continue to remain impacted.

We are currently implementing remedial action to mitigate the issue in the meantime. Follow the latest from GCP in the statuspage at https://status.cloud.google.com/incidents/Xs2XTHzAVC9YnafnPyzj.

Functionality should now be restored across the affected Aura services. We will monitor the situation closely before considering this resolved.

We are continuing to monitor the situation with GCP at the current time and at this point we have seen no new issues.

This incident has been resolved

We are investigating an issue impacting metrics in the Aura Console and via the metric endpoint.

We have identified that a Cloud Service Provider related issue is impacting the current issue. We have opened a support case with the Cloud Service Provider and will update further once we have more detail.

We believe that the Cloud Service Provider issue has been resolved, as we are no longer seeing issues from our internal systems. We will continue to monitor the situation, while we wait for confirmation from the Cloud Service provider.

We have had confirmation from the Cloud Service Provider that the issue has now been fully resolved.

_**Errors when sending metrics from GCP europe-west1**_ _**What happened**_ _On Tuesday, October 13, 2026 at 08:54 UTC, metrics for instances in GCP europe-west1 stopped being delivered and could not be read. The cause was an issue on the Google Cloud side, where a capacity reduction in its monitoring service led to valid requests being incorrectly rejected. Metrics returned to normal at 10:49 UTC after Google Cloud applied a fix, and we resolved the incident at 12:08 UTC once Google Cloud confirmed full resolution._ _Instances remained available throughout this event, with no impact to query performance or data integrity. Only metrics visibility was affected._ _**How the service was affected**_ _Customers saw some short gaps in instance metrics:_ * _**Console metrics:** Instances in GCP europe-west1 may have shown incomplete or missing metric data during the incident window._ * _**Cloud Monitoring Integration \(CMI\):** Metrics forwarded to your own monitoring systems from this region may also have had gaps._ _Not all instances in the region were impacted, and other cloud providers and regions were unaffected. Metrics generated during the incident were not recorded, so the gap will remain in historical charts for affected instances._ _**What we are doing now**_ _The fix came from Google Cloud on this occasion, but our metrics pipeline relied on a single-region path, so we are taking steps to reduce that exposure:_ * _**Regional resilience:** We are evaluating cross-region routing so metrics traffic can fail over to a healthy region._ * _**Traffic routing:** We are exploring options in our cloud networking layer to reroute both reads \(Console and CMI\) and writes \(ingestion\) away from an impacted region._

We are investigating an issue with metrics in the Aura Console and via the metric endpoint.

We continue to investigate the root cause. The issue is limited to customers on us-central1 on GCP Aura instances are running and no operation is affected.

We are working with the cloud service provider to investigate the nature of the issue. Our checks confirm that only a subset of customers running in the us-central1 regions are affected.

We continue to work with the cloud service provider to get a solution.

We continue to work with the cloud service provider to get a solution.

This incident has now been resolved, metrics should now operate as normal.

_**Errors when sending metrics from GCP us-central1**_ _**What happened**_ _On Thursday, October 8, 2026 at 14:05 UTC, metrics from some instances in GCP us-central1 stopped being delivered. The cause was an issue on the Google Cloud side that incorrectly rejected valid metric requests. Metric delivery resumed at 18:00 UTC after Google Cloud applied a fix, and we resolved the incident at 18:48 UTC._ _Instances remained available throughout this event, with no impact to query performance or data integrity. Only metrics visibility was temporarily affected._ _**How the service was affected**_ _Customers saw gaps in instance metrics:_ * _**Console metrics:** Instances in GCP us-central1 may have shown incomplete or missing metric data during the incident window._ * _**Cloud Monitoring Integration \(CMI\):** Metrics forwarded to your own monitoring systems from this region may also have had gaps._ _Not all instances in the region were affected, and other cloud providers and regions were unaffected._ _**What we are doing now**_ _The fix came from Google Cloud, but we are taking steps to catch and respond to similar events sooner:_ * _**Alerting on metric delivery errors:** We are adding alerting on metric forwarding error rates, so provider-side failures are detected earlier and distinguished from routine gaps._ * _**Continued monitoring:** We will keep monitoring the region with Google Cloud for any recurrence._

We are investigating an issue where, despite backups completing successfully, snapshot downloads are returning blank dumps. Restoring from a snapshot through the Aura console or API is not believed to be affected, and we are verifying this now. We will share an update as soon as we have more information.

We are continuing to investigate the issue. Restore operations are not affected as part of this issue.

We are continuing to investigate this issue.

We are continuing to investigate the issue.

A fix has been deployed; snapshot downloads now contain the appropriate data.

# What happened On Fri, 18 Sep 2026 14:33 UTC, we identified that snapshot downloads for Aura instances hosted on Azure were returning files of approximately 24KB instead of the expected multi-gigabyte size. The underlying backups stored in Azure were the correct size, but the download path in the console was serving near-empty files. The root cause was an Azure credential issue that occurred during a deployment and prevented backup data from being served for download. An initial fix was deployed on Mon, 21 Sep 2026 10:31 UTC, restoring correct download sizes. However, the same credential issue recurred on Tue, 06 Oct 2026 08:20 UTC, again producing blank snapshot downloads across all Azure tiers. Our engineering team identified the recurrence, linked it to the same root cause, deployed a targeted credential fix to production, and verified that downloads returned to their expected size. We did not post to the status page on September 18 because a small number of customers were affected, and we worked with them directly. We posted on October 6 at 09:22 UTC, about an hour after the recurrence began, once it was clearly broader. # How the service was affected Snapshot downloads were impacted for AuraDS Professional and Enterprise, AuraDB Professional, Business Critical and Virtual Dedicated Cloud instances running on Azure. * Snapshot downloads returned unusable files. When customers downloaded snapshots from the console, they received files of roughly 24KB instead of the actual backup data, which could be several gigabytes in size. This made the downloaded snapshots unusable for offline restore or migration purposes. * Backups themselves were not lost. The underlying backup artifacts stored in Azure remained intact and correctly sized. The issue was strictly in the download path, not in the backup capture or storage process. * Restoring via the console was unaffected. In-platform restore operations \(as opposed to downloading a dump file\) continued to function because they accessed the backup data directly rather than through the affected download path. # What we are doing now We have taken multiple steps to resolve the issue and have implemented safeguards to prevent recurrence. * Credential fix deployed. We corrected the Azure credential issue in production, which immediately restored snapshot downloads for all affected instances. * Preventing unintended credential rotation. A code change has been submitted to revert the logic that was triggering Azure credential rotation on every deployment. This ensures that future deployments will not inadvertently invalidate existing credentials, which was the mechanism that caused both the initial incident and its recurrence. * Ongoing monitoring. We are monitoring Azure snapshot downloads across all tiers to confirm they remain stable. We have asked affected customers to verify that their downloads now return the expected file sizes. These changes address both the immediate symptom and the underlying deployment behavior that allowed the issue to recur