78 Elastic Cloud incidents · Oktober 2025 — official updates, affected components, duration and resolution details.
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.
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.
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.
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
We are investigating failures with Serverless project creation.
We're currently investigating an issue affecting Serverless project creation and modifications. You may experience delays or failures when creating new projects or updating existing project settings. What's affected: - Creating new Serverless projects - Modifying project settings in the Cloud UI or over the API What's not affected: - Running Serverless projects continue to operate normally - Existing project workloads are unimpacted We'll provide an update within 2 hours, or sooner if the situation changes.
We've identified and resolved the issue affecting Serverless project creation and modifications. Our fix has been deployed, and all services are operating normally. Current status: - Creating and modifying Serverless projects is fully operational - All systems are performing as expected We're continuing to monitor closely for any recurrence.
We've resolved the issue affecting Serverless project creation and modifications. All systems are now operating normally.
On 2026-08-06 between 0900 - 1200 UTC, customers in GCP asia-south1 may have experienced high latency when communicating with their Elasticsearch deployments during this window. The cause has been identified and mitigated.
Elasticsearch 9.5.0 contains a defect that can cause searches to return incorrect results for any index or data stream that disables indexing on a queried field . A query that excludes values using a must_not clause may fail to exclude them when the targeted field has doc values enabled but is not indexed for search. Affected searches can return documents that should have been excluded and report higher document counts than expected, and results may vary between runs of the same query. No error is raised, so affected queries appear to succeed. Dashboards, alerting rules, and anything else built on these searches may report inaccurate values. Both the query DSL and ES|QL are affected. Time series (TSDB) data streams are the most likely to be affected, because indexing is disabled by default for these fields. Columnar indices, currently in technical preview, are affected for the same reason. Any index or data stream that disables indexing on a queried field can be affected. This affects Elasticsearch 9.5.0 on Elastic Cloud Hosted, Elastic Cloud Enterprise, and self-managed deployments, as well as Elasticsearch Serverless projects. Elasticsearch 9.4.x and earlier are not affected. There is no impact to cluster availability, connectivity, or data ingestion. What you can do: - If you have not yet upgraded to 9.5.0, we recommend deferring the upgrade until a fixed version is available. - If you are already running 9.5.0, 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 by 10:00 UTC August 6.
Further investigation confirmed the impact of this issue was limited to boolean queries containing a must, filter, or should clause, along with a must_not clause on unindexed fields. Such queries can return false-positives returning documents that should have been excluded and report higher document counts than expected. We have identified the root cause, a fix is in progress, and we are preparing a patch release. We will provide a further update by 10:00 UTC August 6.
A patch release containing the fix is in progress and it is expected to be available within the next week. Our recommendation to defer upgrading to 9.5.0 until 9.5.1 is available remains unchanged.
Elasticsearch 9.5.1 has been released and contains the fix for this issue. Customers running 9.5.0 should upgrade to 9.5.1. At this time we are considering this issue resolved and will be providing no further updates.
Wir haben ein Problem mit unserer Messung der Instanzkapazität für gehostete Bereitstellungen identifiziert, das eine Teilmenge von Kunden betrifft. Wir glauben derzeit, dass die Auswirkungen auf eine kleine Anzahl von Kunden begrenzt sind, arbeiten aber immer noch daran, alle Vorkommnisse dieses Problems zu identifizieren und zu korrigieren. Wir werden bei Bedarf proaktiv Rechnungskorrekturen vornehmen.
Wir untersuchen immer noch das Messwesenproblem, das eine kleine Anzahl von Kunden betrifft. Wir werden bei Bedarf proaktiv Rechnungskorrekturen vornehmen. Wir werden ein weiteres Update bereitstellen, wenn neue Informationen verfügbar sind.
Wir untersuchen immer noch das Messwesenproblem, das eine kleine Anzahl von Kunden betrifft. Wir werden ein weiteres Update bereitstellen, wenn neue Informationen verfügbar sind.
Alle Dosierfehler wurden korrigiert. Wir werden Rückerstattungen an die kleine Anzahl der betroffenen Kunden ausstellen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
RESOLVED - Zwischen Jul 18 02:40 UTC und Jul 20 14:00 UTC konnte eine Untergruppe von Elastic Agents keine Metriken an AutoOps in allen Regionen melden. Das zugrunde liegende Problem wurde korrigiert und die Daten fließen normal. Betroffene Bereitstellungen können während dieses Zeitraums einige Lücken in ihren AutoOps-Überwachungsdaten feststellen. Beachten Sie, dass dieser Vorfall bereits behoben wurde und rückwirkend veröffentlicht wird.
Dieser Vorfall wurde am Jul 20 14:00 UTC gelöst und rückwirkend veröffentlicht.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen derzeit ein Problem der Multi-Faktor-Authentifizierung (MFA) per E-Mail für Elastic Cloud-Benutzer mit Gmail-Konten. Betroffene Benutzer können lange Verzögerungen oder Ausfälle beim Empfang ihrer E-Mail-MFA-Code auftreten. Verfügbare Workarounds: - Verwenden Sie einen alternativen MFA-Faktor, wenn registriert (Authenticator App / TOTP oder WebAuthn). - Authentifizierung mit dem "Anmelden mit Google" Social Login-Button. Hinweis: Der API-Schlüsselzugriff auf Ihre Projekte und Bereitstellungen bleibt voll funktionsfähig. Wir arbeiten aktiv mit unseren Partnern zusammen, um dieses Problem zu lösen und werden so schnell wie möglich ein Update bereitstellen.
Update: Dieser Vorfall dauert noch an und wir werden weiter untersuchen. Wir untersuchen derzeit ein Problem der Multi-Faktor-Authentifizierung (MFA) per E-Mail für Elastic Cloud-Benutzer mit Gmail-Konten. Betroffene Benutzer können lange Verzögerungen oder Ausfälle beim Empfang ihrer E-Mail-MFA-Code auftreten. Verfügbare Workarounds: - Verwenden Sie einen alternativen MFA-Faktor, wenn registriert (Authenticator App / TOTP oder WebAuthn). - Authentifizierung mit dem "Anmelden mit Google" Social Login-Button. Hinweis: Der API-Schlüsselzugriff auf Ihre Projekte und Bereitstellungen bleibt voll funktionsfähig. Wir arbeiten aktiv mit unseren Partnern zusammen, um dieses Problem zu lösen und werden so schnell wie möglich ein Update bereitstellen.
Update: Dieser Vorfall dauert noch an und wir werden weiter untersuchen.
Lieferverzögerungen wurden gemindert. Wir werden weiterhin überwachen, um sicherzustellen, dass die Lieferung stabil bleibt.
Lieferverzögerungen wurden behoben, die MFA-E-Mail-Zustellung ist für alle Kunden voll funktionsfähig.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Gelöst – Dieser Vorfall ist gelöst. Zwischen Jul 18 02:40 UTC und Jul 20 14:00 UTC konnte eine Untergruppe von Elastic Agents keine Metriken an AutoOps in allen Regionen melden. Das zugrunde liegende Problem wurde korrigiert und die Daten fließen normal. Betroffene Bereitstellungen können während dieses Zeitraums einige Lücken in ihren AutoOps-Überwachungsdaten feststellen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen Fehler mit unserer Cloud-Konsole, die den Zugriff auf das Erstellen, Aktualisieren, Löschen und Anzeigen von Elastic Cloud Hosted-Bereitstellungen beeinflussen. Unser Team untersucht aktiv die Ursache, damit es den Service mildern und wiederherstellen kann.
Die Möglichkeit, Elastic Cloud Hosted-Bereitstellungen über die Cloud Console zu verwalten, wurde wiederhergestellt
Dieser Vorfall wurde behoben
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen ein Problem, das Kunden daran hindert, sich mit ihren Microsoft-Anmeldedaten gegenüber Elastic Cloud zu authentifizieren
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir haben anhaltende Auswirkungen für eine Teilmenge der betroffenen Kunden identifiziert, die EIS verwenden. Unser Team untersucht ein Problem mit der vorherigen Sanierung und arbeitet daran, dass alle betroffenen Umgebungen vollständig wiederhergestellt werden.
Das Problem, das eine Teilgruppe von Kunden mit EIS in EMEA-Regionen betrifft, wurde gemildert und der Service wurde wiederhergestellt.
Der Vorfall, der eine Teilgruppe von Kunden mit EIS in EMEA-Regionen betrifft, wurde behoben. Die Dienste wurden vollständig wiederhergestellt und das Team hat die Stabilität bestätigt.
Automatisch aus der offiziellen Störungsmeldung übersetzt.