78 Elastic Cloud incidents · październik 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.
Update: This incident is still ongoing and we are continuing to investigate.
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.
Zidentyfikowaliśmy problem z naszym pomiarem mocy produkcyjnych dla Hosted Deloyments, który ma wpływ na podzbiór klientów. Obecnie uważamy, że wpływ ten ogranicza się do niewielkiej liczby klientów, ale nadal pracuje nad zidentyfikowaniem i poprawą wszystkich zdarzeń związanych z tą kwestią. W razie potrzeby będziemy aktywnie wydawać korekty rozliczeń.
Wciąż badamy kwestię pomiarów wpływających na niewielką liczbę klientów. W razie potrzeby będziemy aktywnie wydawać korekty rozliczeń. Dostarczymy kolejną aktualizację, gdy będą dostępne nowe informacje.
Wciąż badamy kwestię pomiarów wpływających na niewielką liczbę klientów. Dostarczymy kolejną aktualizację, gdy będą dostępne nowe informacje.
Wszystkie błędy pomiaru zostały poprawione. Będziemy wydawać refundacje dla niewielkiej liczby poszkodowanych klientów.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
RESOLVED - Między 18 lipca 02: 40 UTC a 20 lipca 14: 00 UTC, podzbiór agentów Elastycznych nie był w stanie zgłosić pomiaru do AutoOps we wszystkich regionach. Podstawowa kwestia została poprawiona i dane płyną normalnie. W tym czasie możliwe jest wykrycie pewnych luk w danych z monitorowania AutoOps. Zauważ, że ten incydent został już rozwiązany i jest publikowany z mocą wsteczną.
Ten incydent został rozwiązany 20 lipca 14: 00 UTC, i został opublikowany z mocą wsteczną.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy problem wpływający na uwierzytelnianie wielu czynników (MFA) przez e-mail dla użytkowników Elastic Cloud z kontami Gmail. Dotknięci użytkownicy mogą doświadczyć długich opóźnień lub awarii podczas otrzymywania kodu MFA e-mail. Dostępne Workarounds: - Użyj alternatywnego współczynnika MFA, jeśli jest zarejestrowany (Authenticator App / TOTP lub WebAuthn). - Uwierzytelnij za pomocą przycisku "Zaloguj się z Google". Uwaga: Klucz API dostępu do projektów i wdrożeń pozostaje w pełni operacyjny. Aktywnie współpracujemy z naszymi partnerami w celu rozwiązania tej kwestii i jak najszybciej przedstawimy aktualizację.
Aktualizacja: Ten incydent nadal trwa, a my kontynuujemy śledztwo. Obecnie badamy problem wpływający na uwierzytelnianie wielu czynników (MFA) przez e-mail dla użytkowników Elastic Cloud z kontami Gmail. Dotknięci użytkownicy mogą doświadczyć długich opóźnień lub awarii podczas otrzymywania kodu MFA e-mail. Dostępne Workarounds: - Użyj alternatywnego współczynnika MFA, jeśli jest zarejestrowany (Authenticator App / TOTP lub WebAuthn). - Uwierzytelnij za pomocą przycisku "Zaloguj się z Google". Uwaga: Klucz API dostępu do projektów i wdrożeń pozostaje w pełni operacyjny. Aktywnie współpracujemy z naszymi partnerami w celu rozwiązania tej kwestii i jak najszybciej przedstawimy aktualizację.
Aktualizacja: Ten incydent nadal trwa, a my kontynuujemy śledztwo.
Opóźnienia dostaw zostały ograniczone. Będziemy nadal monitorować, aby zapewnić stabilność dostaw.
Opóźnienia dostawy zostały rozwiązane, dostawy e-mail MFA jest w pełni funkcjonalny dla wszystkich klientów.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Rozwiązanie - Ten incydent został rozwiązany. Między 18 lipca 02: 40 UTC a 20 lipca 14: 00 UTC, podzbiór Agentów Elastycznych nie był w stanie zgłosić pomiaru do AutoOps we wszystkich regionach. Podstawowa kwestia została poprawiona i dane płyną normalnie. W tym czasie możliwe jest wykrycie pewnych luk w danych z monitorowania AutoOps.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Badamy błędy z naszą konsolą w chmurze wpływające na dostęp do tworzenia, aktualizacji, usuwania i wyświetlania elastycznych aplikacji w chmurze Hosted. Nasz zespół aktywnie bada sprawę, aby złagodzić i przywrócić usługę.
Zdolność do zarządzania elastyczną chmurą Hosted za pośrednictwem konsoli Cloud została przywrócona
Ten incydent został rozwiązany
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Badamy problem, który uniemożliwia klientom uwierzytelnienie przed Elastic Cloud za pomocą ich Microsoft logowania
Ten incydent został rozwiązany.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Zidentyfikowaliśmy stały wpływ na podzbiór poszkodowanych klientów korzystających z EIS. Nasz zespół bada problem z poprzednią rekultywacją i pracuje nad zapewnieniem pełnego przywrócenia wszystkich dotkniętych środowisk.
Kwestia dotykająca podzbiór klientów z EIS w regionach EMEA została złagodzona, a usługa została przywrócona.
Incydent wpływający na podgrupę klientów w regionach EMEA został rozwiązany. Usługi zostały w pełni przywrócone, a zespół potwierdził stabilność.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.