Elasticsearch 9.5.0 contains a query-correctness defect
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.
The latest update from Elastic Cloud.
State
Resolved
Started
87 d ago
2026-08-05 22:59 UTC
Lasted
6 days
until 2026-08-12 08:59 UTC
Worst impact
Partial outage
Timeline
4 updatesIdentified
6 days 100%
Updates
Times in UTCAs posted by Elastic Cloud
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.
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.
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.
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
Elastic Cloud in the last 90 days
Full historyIncidents in 90 days
24
Days with an incident
90
Median duration
4 h 48 min
This incident
32× the median
Other Elastic Cloud incidents
All incidentsElastic Cloud·Elastic Support Portal is unavailable
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.
Elastic Cloud·403 error when trying to access Autoops in newly created serverless projects
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.
Elastic Cloud·Elastic Cloud scaling issues in Azure
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.
Elastic Cloud·Degraded availability for some Elastic Cloud Hosted and Serverless deployments in GCP europe-west2 (London)
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.
Elastic Cloud·Delayed or Unavailable project operation in GCP us-central1
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.
Follow Elastic Cloud
Your coding agent knows when Elastic Cloud is down, and tells you when a failure is theirs, not yours. You can also get Elastic Cloud incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "elastic" and tell me if Elastic Cloud has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=elastic/feed subscribe https://outages.cc/feed.xml?providers=elasticFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane