Issue impacting Aura instance operations

We are currently investigating an issue at this time.

We are working with engineering teams and making progress with the investigations at the current time.

We are working with engineering teams and continuing to make progress with the investigations at the current time.

We have identified the cause of the current issue and are actively working on the fix currently.

We are deploying the first part of the fix and continue actively working on rolling out the full solution. We expect an ETA in the order of 1hour from now.

We have identified the subset of instances impacted and continue to deploy the fix at this time.

We have deployed a configuration fix and are now working to resolve the subset of instances impacted.

With the configuration fix deployed, we are continuing to resolve the subset of instances still impacted.

We are continuing to resolve the subset of instances still impacted.

We are continuing to resolve the subset of instances still impacted.

We are continuing to resolve the subset of instances still impacted.

We continue to resolve the subset of instances which are still impacted.

We continue to resolve the subset of instances which are still impacted.

AuraDB Virtual Dedicated Cloud and AuraDB Business Critical should all now be fixed. We continue to resolve the subset of instances which are still impacted for AuraDB Professional and Free.

We continue to resolve the subset of instances which are still impacted for AuraDB Professional and Free.

We continue to resolve the subset of instances that are still impacted for AuraDB Professional and Free.

We continue to resolve the subset of instances that are still impacted for AuraDB Professional and Free

We continue to fix a subset of instances that are still impacted for AuraDB Professional and Free

We continue to fix a small subset of instances that are still impacted under the AuraDB Professional and Free tiers.

We addressed the issue in all AuraDB Professional instances. Aura Free can still be affected. We will continue to monitor and fix the remaining databases.

We continue to fix a small subset of Free instances that are still impacted.

We are continuing to monitor for any further issues.

We are continuing to monitor for any further issues.

We are continuing to monitor the situation closely for any further issues.

We are continuing to monitor the situation closely for any further issues.

We are continuing to monitor for any further issues.

All identified instances have been fix, continuing to monitor. Contact customer support for any further issues.

All fixes have been deployed and issue is now marked as resolved.

### What happened

On 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.

The 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.

Once 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.

By 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.

### How the service was affected

The 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.

• 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.
• Stuck updates: Additional instances remained available but were stuck in an "Updating" state, which blocked customer-initiated operations such as resizes or configuration changes.
• Cross-platform scope: The impact spanned all three supported cloud providers and multiple regions, affecting customers globally.

Customer 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.

### What we are doing now

We have carried out a thorough analysis of this incident and have identified the following actions:

• Prevention

• Improved deployment validation: We are strengthening our release validation process to better identify configuration changes.
• Component decoupling: We are evaluating improvements to the sequencing of component deployments to reduce the risk of unintended changes being included in releases.
• 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.

• Detection

• 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.

• Mitigation

• 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.
• Faster manual recovery tooling: We are improving our recovery tooling to reduce the time required to identify and manually recover affected instances.

We 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.