Elastic Cloud outage history

We are currently investigating an issue preventing access to the Elastic Support portal. At this time, customers may experience issues authenticating to the support portal.

We have identified an issue preventing access to the Elastic Support portal caused by an upstream provider. The provider has confirmed a fix that has restored access for some of its affected environments and is now rolling it out to the rest. At this time, customers may experience issues authenticating to the support portal.

The upstream provider has completed its fix, and access to the Elastic Support portal has been restored. Customers can authenticate to the support portal again. We are considering this issue resolved and will be providing no further updates. If you continue to have issues, please contact us.

We are investigating an issue affecting AutoOps for newly created accounts in the AWS us-east-1 region. Accounts created after 00:00 UTC on October 22, 2026 may be unable to access AutoOps and may see an error (HTTP 403) when opening it. Elastic Cloud Hosted: AutoOps is not available for affected new accounts. Elastic Cloud Serverless: AutoOps is not available for affected new accounts. Existing deployments and projects, and all other Elastic Cloud functionality, are not affected. Our engineering teams are working to identify the cause and restore access. We will provide the next update within 60 minutes, or sooner if there is a significant change

We have identified the cause of the issue affecting AutoOps and are deploying a fix. Elastic Cloud Hosted and Elastic Cloud Serverless: Customers who created a new account in the AWS us-east-1 region since approximately 00:30 UTC on October 22, 2026 were unable to access AutoOps and may have seen an error (HTTP 403) when opening it. The fix is rolling out now, and we expect the situation to be fully resolved by 13:00 UTC. Existing deployments and projects, and all other Elastic Cloud functionality, are not affected.

We resolved the issue affecting AutoOps at 12:30 UTC. Elastic Cloud Hosted and Elastic Cloud Serverless: Customers who created a new account in the AWS us-east-1 region since approximately 00:30 UTC on October 22, 2026 were unable to access AutoOps and may have seen an error (HTTP 403) when opening it.

We are investigating an issue affecting the ability to scale existing Elastic Cloud Hosted deployments and Serverless projects in Azure. New project and deployment creation in Azure may be delayed.

We have identified an issue affecting the ability to scale existing Elastic Cloud Hosted deployments and Serverless projects in Azure. New project and deployment creation in Azure may be delayed. Engineers are actively working to mitigate the issue.

Engineers have identified and mitigated an issue affecting the ability to scale existing Elastic Cloud Hosted deployments and Serverless projects in Azure. We are monitoring the issue to ensure operations continue normally.

Engineers have mitigated an issue affecting the ability to scale existing Elastic Cloud Hosted deployments and Serverless projects in Azure. Scaling is working as expected.

We are investigating an issue affecting one availability zone in the GCP europe-west2 (London) region. Starting at approximately 06:15 UTC, some Elastic Cloud Hosted and Serverless deployments with capacity in this zone may experience degraded availability or connectivity. Monitoring and logging for deployments in the region may also be delayed. Deployments in other zones and regions are not affected. Our engineers are actively working on the issue, and we are in contact with our cloud provider.

Our cloud provider has confirmed an infrastructure incident affecting a single availability zone (europe-west2-b) in the GCP europe-west2 (London) region, causing network connectivity loss and resource unavailability in that zone. Elastic Cloud Hosted deployments and Elastic Serverless projects with resources in the affected zone may be unavailable or experience degraded performance. We have taken steps to avoid placing new Serverless projects in the affected zone, and we are working to restore services that depend on it. Reduced capacity in the region may delay scaling and the creation of new resources. We do not yet have an estimated time for recovery from our cloud provider. We are working closely with them and will provide the next update within an hour.

The infrastructure incident at our cloud provider affecting availability zone europe-west2-b in the GCP europe-west2 (London) region is ongoing. Elastic Cloud Hosted: Most deployments with resources in the affected zone remain unavailable or degraded. We are seeing early, limited signs of recovery, and a small number of the initially affected deployments are recovering. We are continuing our mitigation work and will share more as recovery progresses. Elastic Serverless: We have taken steps to avoid placing new projects in the affected zone, and we are now rebalancing existing projects to other availability zones. We are seeing signs of recovery -  some projects remain unavailable or degraded in the meantime. Reduced capacity in the region may delay scaling and the creation of new resources. We do not yet have an estimated time for full recovery from our cloud provider. We are working closely with them and will provide the next update by 10:15am UTC.

The infrastructure incident at our cloud provider affecting availability zone europe-west2-b in the GCP europe-west2 (London) region is ongoing. Elastic Cloud Hosted deployments and Elastic Serverless projects with resources in the affected zone may remain unavailable or degraded. Our teams are continuing to work on mitigation and recovery, and we are working closely with our cloud provider. We do not yet have an estimated time for full recovery. We will provide the next update by 12:00 UTC, or sooner if there is a significant change.

The infrastructure incident at our cloud provider affecting availability zone europe-west2-b in the GCP europe-west2 (London) region is ongoing. We are seeing slight signs of recovery, both from our cloud provider and from our own mitigation work. Elastic Cloud Hosted: Some of the affected deployments are recovering. Customers whose plan changes or other operations failed during the incident are advised to retry them from the Elastic Cloud console. Operations that depend on the affected zone may take longer than usual, or fail again, until recovery progresses further. Some deployments may remain unavailable or degraded. Elastic Serverless: Some projects may remain unavailable or degraded.

The infrastructure incident at our cloud provider affecting availability zone europe-west2-b in the GCP europe-west2 (London) region is recovering. Our cloud provider reports recovery of services for most workloads in the region, and we are seeing progress on our side as the affected zone comes back. Elastic Cloud Hosted: An increasing number of affected deployments are recovering. Customers whose plan changes or other operations failed during the incident are advised to retry them from the Elastic Cloud console. Some deployments may still be unavailable or degraded, and some may need additional recovery steps that our Support team will work through case by case. If your deployment is still unhealthy, please contact Support. Operations may take longer than usual while capacity is restored.

The infrastructure incident at our cloud provider affecting availability zone europe-west2-b in the GCP europe-west2 (London) region has been resolved. We are continuing to work towards full recovery of our services. Elastic Cloud Hosted: An increasing number of affected deployments are recovering. Customers whose plan changes or other operations failed during the incident are advised to retry them from the Elastic Cloud console. Some deployments may still be unavailable or degraded, and some may need additional recovery steps that our Support team will work through case by case. If your deployment is still unhealthy, please contact Support. Operations may take longer than usual while capacity is restored.

The infrastructure incident at our cloud provider affecting availability zone europe-west2-b in the GCP europe-west2 (London) region has been resolved. Engineering has completed recovery of infrastructure running in the affected availability zone. Elastic Cloud Hosted: Customers whose plan changes or other operations failed during the incident are advised to retry them from the Elastic Cloud console. Some deployments may still be unavailable or degraded, and may need additional recovery steps that our Support team will work through case by case. If your deployment is still unhealthy, please contact Support.

We are investigating an issue affecting some Elastic Cloud Serverless projects in the GCP us-central1 region. Customers may experience delayed or unavailable project operation.

We have identified an issue with cloud storage affecting some Elastic Cloud Serverless projects in the GCP us-central1 region. Customers may experience delayed or unavailable project operations. The provider is investigating the issue, and we are monitoring recovery. We will provide another update when more information is available.

Some Elastic Cloud Serverless projects in the GCP us-central1 region may still experience delayed or unavailable project operations. The provider is continuing to investigate the issue. We are monitoring the situation and will provide another update when more information is available.

We have observed improvements after mitigations were applied by our upstream cloud storage provider. Some Elastic Cloud Serverless projects in the GCP us-central1 region may still experience delayed or unavailable project operations while recovery continues. We are monitoring the situation and will provide another update when more information is available.

The upstream cloud storage issue affecting some Elastic Cloud Serverless projects in the GCP us-central1 region has been resolved. Project operations have returned to normal, and we are no longer seeing affected projects in a red health state.

Customers with Serverless projects in the Azure UAE North region may see delays in metrics displayed in Cloud UI. The team is investigating the issue and we will post an update in 2 hours or sooner if necessary

The issue affecting metric availability for Serverless projects in Azure UAE North has been resolved. Delayed “Usage and performance” metrics are now recovering, and queued usage records are being processed. No data loss is expected.

We are currently experiencing delays in provisioning new cloud resources due to slowness with an external container image provider. This may result in delays when creating new deployments, scaling existing ones, or relocating instances affected by infrastructure maintenance. As mitigation, you can try re-running failed plan changes. Existing running deployments are not impacted. Our team is actively monitoring the situation and working to mitigate the issue. We will provide an update in the next 12 hours.

This issue has been resolved.

We are investigating reports of missing node-level metrics (CPU, memory, disk, thread pools) for recent time ranges in a subset of AutoOps regions. This may appear as a "No data" message on the Nodes view. Cluster health, shard, and deployment data are unaffected, and no data loss has occurred. We will provide an update within the next 2 hours or earlier.

We've identified the cause of the missing node-level metrics (CPU, memory, disk, thread pools) in affected regions. Cluster health, shard, and deployment data were never affected, and no data loss has occurred. A fix has been validated in one region and is now being rolled out to the remaining affected regions. We'll provide a further update once the rollout is complete.

The issue causing missing node-level metrics (CPU, memory, disk, thread pools) for recent time ranges in a subset of AutoOps regions has been fully resolved. Cluster health, shard, and deployment data were unaffected throughout, and no data was lost.

We are currently aware that some customers may be unable to access the Elastic Support Portal at this time. We are working with our provider to investigate. If you need to contact support in the meantime, please contact [email protected].

We are seeing signs of recovery on the Elastic Support Portal, and customers should now be able to access as normal. We will continue monitoring for 30 minutes before marking this incident as resolved.

The Elastic Support Portal remains available and steady - at this time, we are considering this incident resolved.

We are investigating metrics delays in the console.

We've identified and fixed the cause of the metrics delay. The queue is being processed and delayed metrics will be viewable when complete.

Metrics queues are being processed and delayed data is starting to show again. We'll monitor to be sure everything catches up as expected.

The metrics ingestion delay in GCP us-east4 has been fully resolved. All queued data has been processed and metrics are now showing in the console in real time.

We have identified and are in the process of fixing+mitigating a bug in our permissions management UI that is prevents users with the Organisation Owner role and Cloud Console, Elasticsearch, and Kibana access from accessing Kibana in Hosted Deployments.

Update: This incident is still ongoing and we are continuing to investigate.

Update: The fix has been deployed to production and we have applied a data correction to affected accounts, restoring Kibana access for impacted users. We are monitoring to confirm full resolution.

This incident has been resolved.

We've identified a bug in Fleet Server 9.5.3 (also present in 9.4.6) that can cause Elastic Agents to crash-loop and go offline when Fleet pushes a configuration update, including enrollment, a policy change, or a routine revision bump. This only affects policies that use Fleet's remote Elasticsearch output feature. Recommendation: If you use Fleet's remote Elasticsearch output, do not upgrade to 9.5.3 or 9.4.6 until a fixed version is available. If you're already on an affected version and experiencing agent check-in failures, contact Support for remediation steps. A fix has been merged and will ship in the next 9.5.x and 9.4.x releases. Known Issue documentation: fleet-server#7791, elastic-agent#16542.

We have patched Fleet Server versions 9.5.3 and 9.4.6 with corrected releases deployed as of September 10, 2026 at 21:20 UTC. - Upgrading to the current 9.4.6 or 9.5.3 releases will not be affected by this bug as the updated release contains the fix. - If you upgraded to 9.4.6 or 9.5.3 before 21:20 UTC on 10 September 2026, perform the following mitigation: 1. Force restart the Integration Server component of you affected deployment 2. Run cleanup procedures on affected Elastic Agents (see https://support.elastic.co/knowledge/bee1c75c) — required if agents failed to check in or remained offline after the Integration Server restart

We have patched Fleet Server versions 9.5.3 and 9.4.6 with corrected releases deployed as of September 10, 2026 at 21:20 UTC. - Upgrading to the current 9.4.6 or 9.5.3 releases will not be affected by this bug as the updated release contains the fix. - If you upgraded to 9.4.6 or 9.5.3 before 21:20 UTC on 10 September 2026, perform the following mitigation: 1. Force restart the Integration Server component of you affected deployment 2. Run cleanup procedures on affected Elastic Agents (see https://support.elastic.co/knowledge/bee1c75c) — required if agents failed to check in or remained offline after the Integration Server restart IMPORTANT: The patched Fleet Server is not available outside Elastic Cloud Enterprise (ECE) Stack Packs and Elastic Cloud Hosted (ECH).

We have confirmed that Elastic Agents are no longer experiencing enrollment failures related to this issue. Corrected Fleet Server releases (9.5.4 / 9.4.6) have been available on Elastic Cloud Hosted and Elastic Cloud Enterprise stack packs since September 10, 2026, and all known affected deployments have confirmed recovery. If you upgraded to an affected release before that time and have not yet applied the mitigation, guidance is available here: https://support.elastic.co/knowledge/bee1c75c.

From 21:50 to 23:42 UTC, we encountered elevated error rates for Anthropic Claude Haiku 4.5, OpenAI GPT-5.6, and Google Gemini 2.5 Flash with the Elastic Inference Service in EU regions. This issue has now been resolved.

We are currently investigating an issue impacting services running in GCP us-central1.  We will provide additional updates as we learn more about the scope of impact.

An ongoing issue is impacting services running in GCP us-central1.  This includes, but is not limited to Elastic Cloud Hosted and Serverless projects in the region and our Docker Registry service.  We are continuing to monitor the situation and will provide updates when they are available.

An ongoing upstream CSP issue is impacting services running in GCP us-central1. This includes, but is not limited to Elastic Cloud Hosted and Serverless projects in the region and our Docker Registry service. We are continuing to monitor the situation and will provide updates when they are available.

We are seeing signs of recovery for services in GCP us-central1 impacted by an upstream CSP issue .  We are continuing to monitor the situation and will provide updates as they become available.

This issue has been resolved.

We are aware of a bug affecting customers on Elasticsearch versions 9.5.0, 9.5.1 and 9.5.2 where bulk index operations processed on the primary shard can result in divergence on the replicas resulting in high disk usage and long-running recoveries. The team is working on a fix. More information can be found on https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.5.2-known-issues The next update will be in the next 2 hours or sooner if needed.

We have identified the root cause and the team is working on a fix scheduled to be released in Elasticsearch version 9.5.3 What you can do: - If you have not yet upgraded to 9.5.*, you are not affected as upgrades to 9.5 have been disabled until 9.5.3 is released - If you are already running 9.5 and experience the symptoms of this issue, please contact Elastic Support. More information can be found on https://www.elastic.co/docs/release-notes/elasticsearch/known-issues#elasticsearch-9.5.2-known-issues

The fix has been identified and backported to the Elasticsearch 9.5 patch branch. The teams are performing the needed validations before scheduling and rolling out the 9.5.3 release.

Elasticsearch 9.5.3 has been released and all customers currently running 9.5.0, 9.5.1 or 9.5.2 are advised to update to this new version as soon as possible.

Elasticsearch 9.5.3 has been released and all customers currently running 9.5.0, 9.5.1 or 9.5.2 are advised to update to this new version as soon as possible. Impacted customers are advised to follow the workaround steps from https://github.com/elastic/elasticsearch/issues/158212 after the upgrade.

This issue was resolved in the 9.5.3 release of Elasticsearch.  Customers running versions 9.5.0, 9.5.1, or 9.5.2 of Elasticsearch are advised to update to a newer version as soon as possible.

On August 26, at around 00:00 UTC we deployed a change in Managed Inputs that affected some rules in our internal DNS provider, removing the .apm endpoints some of our Serverless customers. The service was restored around 9AM UTC on the same day. During this time, some customers would have experienced unavailability of the .apm endpoint, for a period in the 9 hour window. We are putting some checks and alerts in place to ensure this does not happen again.

This is now resolved

We are currently investigating elevated error rates affecting the managed OTLP on Elastic Cloud Serverless. Our team is actively investigating the root cause. We will provide an update within 30 minutes.

We are continuing to investigate elevated error rates affecting the managed OTLP on Elastic Cloud Serverless. We will provide an update within 1 hour.

We have identified the root cause of the elevated error rates affecting serverless managed OTLP. A mitigation has been applied and we are monitoring to confirm error rates return to baseline. Based on our investigation, customer workloads were not affected.

This incident has been resolved. The root cause has been identified and addressed. Customer workloads were not impacted during this incident.

An issue affecting the creation of new Serverless projects in Azure's eastus region has been identified. Our team is actively investigating to determine the root cause. We will provide a follow-up status update within the next hour or as soon as the root cause is established, whichever occurs first.

We have determined that the issue stems from an upstream problem with Azure's storage component. Upon examination, the impact is limited strictly to new project initialization times, resulting in longer creation times for Serverless projects in the Azure eastus region. We will provide a further update once the issue has been resolved.

Azure's storage component issues in the eastus region have been resolved. Consequently, Serverless project creation times have returned to normal and are functioning as expected.

Elasticsearch 9.5.1 contains a known issue where boolean queries containing a must, filter, or should clause using a multi-value terms query, alongside a must_not clause on fields with disabled indexing, can still return false-positive matches. While the patch in 9.5.1 (https://github.com/elastic/elasticsearch/pull/155936) resolved the bulk-scorer defect for term and range query paths; multi-value terms queries utilize a different Lucene query type that was not covered by that fix. Time Series Data Streams (TSDB) and columnar indices/data streams remain affected for this query pattern, as indexing is disabled by default on those fields. Affected terms queries may return false-positive matches (including documents that should have been excluded) and report higher document counts than expected. No error is raised, so queries will appear to complete successfully. What you can do: - If you have not yet upgraded to 9.5.*, we recommend deferring the upgrade until version 9.5.2 is available. - If you are already running 9.5.*, contact Elastic Support if you need help determining whether your searches are affected. We have identified the root cause, a fix is in progress, and we are preparing a patch release. We will provide a further update when the fix is ready.

Elasticsearch 9.5.2 has been released and contains the fix for this issue. Customers running 9.5.0 or 9.5.1 should upgrade to 9.5.2. At this time we are considering this issue resolved and will be providing no further updates.

We are seeing elevated error rates from the upstream provider for the microsoft-multilingual-e5-large embedding model. Search embedding requests to this model may fail. We are investigating

We're seeing some improvement in availability but are continuing to monitor the situation. We will follow up with more information in due course.

Unfortunately, we can no longer support the E5 Multilingual Large model on the Elastic Inference Service due to continued upstream provider issues. Any customers requiring this model should set up custom inference endpoints using their own API keys.

The microsoft-multilingual-e5-large model has been retired from the Elastic Inference Service. Requests to this model now return an error. Customers who wish to use this model with Elastic cloud must create a custom inference endpoint using their own API key. See our inference documentation for further details: https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-inference