Elastic

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

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

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

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

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.

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 support@elastic.co.

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.

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

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

We are investigating metrics delays in the console.

This incident has been resolved.

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.

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

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.

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.

This issue has been resolved.

We are seeing signs of recovery for services in GCP us-central1 impacted by an <a href='https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev'>upstream CSP issue</a>.  We are continuing to monitor the situation and will provide updates as they become available.

An ongoing <a href="https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev">upstream CSP issue</a> 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 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 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.

This is now resolved

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 incident has been resolved. The root cause has been identified and addressed. Customer workloads were not impacted during this incident.

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.

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

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.

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.

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.

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.

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.

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

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.

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

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've resolved the issue affecting Serverless project creation and modifications. All systems are now operating normally.

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'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 are investigating failures with Serverless project creation.

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

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.

Delivery delays have been resolved, MFA email delivery is fully functional for all customers.

Delivery delays have been mitigated. We will continue to monitor to ensure delivery remains stable.

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

Update: This incident is still ongoing and we are continuing to investigate. We are currently investigating an issue affecting multi-factor authentication (MFA) via email for Elastic Cloud users with Gmail accounts. Affected users may experience long delays or failures when receiving their email MFA code. Available Workarounds: - Use an alternative MFA factor if registered (Authenticator App / TOTP or WebAuthn). - Authenticate using the "Log in with Google" social login button. Note: API Key access to your projects and deployments remains fully operational. We are actively collaborating with our partners to resolve this issue and will provide an update as soon as we can.

We are currently investigating an issue affecting multi-factor authentication (MFA) via email for Elastic Cloud users with Gmail accounts. Affected users may experience long delays or failures when receiving their email MFA code. Available Workarounds: - Use an alternative MFA factor if registered (Authenticator App / TOTP or WebAuthn). - Authenticate using the "Log in with Google" social login button. Note: API Key access to your projects and deployments remains fully operational. We are actively collaborating with our partners to resolve this issue and will provide an update as soon as we can.

All metering errors have been corrected. We will be issuing refunds to the small number of affected customers.

We are still investigating the metering issue impacting a small number of customers. We'll provide a further update when new information is available.

We are still investigating the metering issue impacting a small number of customers. We will proactively issue billing corrections where necessary. We'll provide another update when new information is available.

We have identified an issue with our metering of Instance Capacity for Hosted Deployments that affects a subset of customers. We currently believe the impact to be limited to a small number of customers but are still working to identify and correct all occurrences of this issue. We will proactively issue billing corrections where necessary.

This incident was resolved on Jul 20 14:00 UTC, and was posted retroactively.

RESOLVED - Between Jul 18 02:40 UTC and Jul 20 14:00 UTC, a subset of Elastic Agents were unable to report metrics to AutoOps across all regions. The underlying issue has been corrected and data is flowing normally. Impacted deployments may notice some gaps in their AutoOps monitoring data during this timeframe. Note this incident has already been resolved, and is being posted retroactively.

Resolved – This incident is resolved. Between Jul 18 02:40 UTC and Jul 20 14:00 UTC, a subset of Elastic Agents were unable to report metrics to AutoOps across all regions. The underlying issue has been corrected and data is flowing normally. Impacted deployments may notice some gaps in their AutoOps monitoring data during this timeframe.

This incident has been resolved

The ability to manage Elastic Cloud Hosted deployments via the Cloud Console has been restored

We are investigating errors with our cloud console affecting access to create, update, delete and view Elastic Cloud Hosted deployments. Our team is actively investigating the cause so that they can mitigate and restore the service.

This incident has been resolved.

We are investigating a problem that prevents customers from authenticating against Elastic Cloud using their Microsoft login credentials

The incident impacting a subset of customers with EIS in EMEA regions has been resolved. Services have been fully restored and the team has confirmed stability.

The issue affecting a subset of customers with EIS in EMEA regions has been mitigated and the service have been restored.

We have identified continued impact for a subset of affected customers using EIS. Our team is investigating an issue with the previous remediation and is working to ensure all affected environments are fully restored.

The issue affecting EIS for Elastic Cloud customers with projects or deployments on GCP and Azure in EMEA regions has been resolved.

We are currently investigating a partial outage affecting the Elastic Inference Service (EIS) for Elastic Cloud customers with deployments in GCP and Azure in EMEA regions.

We are currently investigating a partial outage affecting the Elastic Inference Service (EIS) for Elastic Cloud customers with deployments in GCP and Azure in EMEA regions.

We are currently investigating a partial outage affecting the Elastic Integration Service (EIS) for Elastic Cloud customers with deployments in GCP and Azure in EMEA regions.

This issue has been resolved.

The system has recovered and we are continuing to monitor the situation.

We have identified the issue and implemented a fix.  We are seeing signs of system recovery and are continuing to monitor the situation closely.

We're experiencing a monitoring data delay affecting a limited number of Azure regions. Elastic Cloud's internal metrics for these regions are being ingested more slowly than usual. What you may notice: Deployment metrics and instance utilization data may not appear in the Elastic Cloud UI for Hosted Deployments and Serverless Projects in affected regions. What's not affected: Your deployments and projects are running normally. Data ingestion and all functionality remain unimpacted besides lacking some monitoring data on the Elastic Cloud UI. We're actively investigating the root cause and will provide an update within the next 2 hours.

This issue has been resolved.

We are continuing to work on a fix for this issue.

We have identified an issue with our ability to deliver certain static assets to our products. We have identified and are working to implement a fix.

This issue has been resolved.

We have identified and deployed a fix for this issue and are continuing to closely monitor the situation.

We are currently investigating an issue when creating/updating Deployments in several regions. We've identified the issue and working on applying a fix. We will provide an update when one is available or within the hour, whichever comes first.

This issue is resolved.

This incident is ongoing. The upstream providers are aware and working to resolve the issue. We will provide an update when the status changes or within an hour, whichever comes first.

We are currently experiencing an issue impacting the ability to ingest data into mOTLP and .amp endpoints in the Azure Australia East region.  The upstream providers are aware and working to resolve the issue.  We will provide an update when the status changes or within an hour, whichever comes first.

We have identified the root cause and mitigated the issue. Users should now be able to log in to Kibana via the "Log in with Elastic Cloud" button.

We are continuing to investigate this issue.

We have detected an issue with the Kibana authentication flow for both Deployments and Projects. Authenticating to Kibana using the "Log in with Elastic Cloud" button results in an authentication failure. A workaround is to access Kibana using the link inside the Elastic Cloud console. We are currently working on a resolution. Our team is currently identifying the root cause to resolve the issue. We will share another update in the next hour.

This issue has been resolved.

This issue has been mitigated, and we are continuing to monitor the situation.

We are currently investigating an intermittent issue which may cause unavailability of Elastic Cloud Serverless projects or the inability to create new Serverless projects in AWS us-east-1.  We will continue to update status as we learn more.

This incident has been resolved.

Customers may see delays with creating Azure serverless projects and existing Azure projects may be temporarily unavailable. We are seeing increased recovery across as we monitor the situation. Services are being restored. Monitoring is continuing, and we will provide further updates as we progress.

Customers may see delays with creating Azure serverless projects and existing Azure projects may be temporarily unavailable. Recovery has started and we will provide further updates as we progress.

Customers may see delays with creating Azure serverless projects and existing Azure projects may be temporarily unavailable. We are currently investigating the issue.

This incident has been resolved.

We are seeing some signs of recovery, and have taken action to mitigate the impact and speed up recovery. Some users will still see seeing missing metrics visualizations in the Cloud console, for deployments in the Azure North Europe region. We are actively investigating and will provide another update within 1 hour

Some users are seeing missing metrics visualizations in the Cloud console due to a disruption in metric data ingestion affecting deployments in the Azure North Europe region. Some recent metric data may not appear in charts or monitoring views. We are actively investigating and will provide another update within 1 hour

This incident has been resolved.

We continue to monitor the situation which has mostly recovered. A small number of deployments are still not healthy. Our support team is working on resolving these on a case-by-case basis.

Remediation is underway and systems are recovering. We  continue to monitor the situation and will post an update in the next 2 hours or earlier.

We continue to remediate the impact of an upstream Azure outage in Azure West US 2 (azure-westus2), limited to availability zone westus2-2. Customers with deployments not configured for high availability in this region may continue to experience intermittent connectivity errors, degraded performance, or delays when performing deployment operations. Deployments configured for high availability across multiple availability zones are not expected to be affected. Our teams remain actively engaged with Microsoft Azure and are working to restore affected infrastructure. We will provide further updates as recovery progresses

We continue to respond to an upstream Microsoft Azure outage in Azure West US 2 (azure-westus2), caused by a datacenter power event reported by Azure. Elastic impact remains limited to availability zone westus2-2. Customers with deployments not configured for high availability in this region may continue to experience intermittent connectivity errors, degraded performance, or delays when performing deployment operations (including create, edit, restart, and delete). Deployments configured for high availability across multiple availability zones are not expected to be affected. Our teams are actively remediating affected infrastructure in the impacted zone. Recovery progress is currently constrained by degraded Azure platform APIs and capacity availability in the region.

We are continuing to investigate the impact of an upstream Azure WestUS2 outage which is impacting Elastic services and deployment healthiness, including Elastic Serverless projects hosted in this region. We have confirmed that impact to our service is limited to a single availability zone (westus2-2). Customers whose deployments are not configured for high availability may experience intermittent errors, delays, or inability to access certain features. Deployments configured for high availability across multiple zones are not expected to be affected. Our team is working to mitigate the situation and the impact on our environment. We will provide further updates as more information becomes available.

We are continuing to investigate this issue.

We are continuing to investigate this issue.

We are continuing to investigate the impact of an upstream Azure WestUS2 outage which is impacting Elastic services and deployment healthiness, including Elastic Serverless projects hosted in this region. We have confirmed that impact to our service is limited to a single availability zone (westus2-2). Customers whose deployments are not configured for high availability may experience intermittent errors, delays, or inability to access certain features. Deployments configured for high availability across multiple zones are not expected to be affected. Our team is working to mitigate the situation and the impact on our environment. We will provide further updates as more information becomes available.

This issue has been resolved.

We're aware of an issue with creating Serverless projects in the AWS ap-southeast-2 region. The engineering team is investigating the problem. We will post the next update in 2 hours.

The permanent resolution has been implemented, thus concluding our resolution actions. This incident is resolved.

We continue to actively monitor the implemented mitigation actions. All new user logins are functioning as expected. A permanent resolution is scheduled to be implemented early next week. Our next update will be once the resolution actions are complete, or sooner if the situation changes.

We have mitigated the issue preventing new Elastic Cloud customers and trial users from accessing AutoOps by restarting a backend service. We are actively monitoring to confirm the fix remains stable and that all new user logins are functioning as expected. We will provide a final update once we have confirmed full resolution.

We are investigating an issue that prevents new Elastic Cloud customers, including trial users, from accessing AutoOps across all regions. Impact: New customers and trial accounts are currently unable to access the AutoOps dashboard. Existing Customers: Service is unaffected. AutoOps continues to function normally for all existing deployments. Our team is actively working to identify the root cause. We will provide our next update within the next hour or as soon as more information becomes available.

Some users experienced missing metrics visualizations in the Cloud console due to a disruption in metric data ingestion affecting deployments in the Azure Southeast Asia region. We have already stabilized the situation.

The system has recovered and functionality has returned to normal.

The problem has been identified and is being stabilized, but metrics visualizations in the Cloud console remains impacted until recovery is complete. We will provide a further update in 1 hour, or when there is a change in status.

Some users are seeing missing metrics visualizations in the Cloud console due to a disruption in metric data ingestion affecting deployments in the Azure North Europe region. Some recent metric data may not appear in charts or monitoring views. We are actively investigating and will provide another update within 1 hour.

Synthetics browser monitors running in Europe-Germany region (GCP europe-west3) for some of the users were experiencing delayed executions results and some of them being stopped. The issue affected both Elastic Cloud Hosted and Elastic Cloud Serverless in that region and other regions were not impacted.

We have confirmed no further impact from this incident, and are now considering this issue resolved. Thank you for your patience.

We are aware of issues resulting in temporary unavailability across multiple Serverless projects. From 08:00 UTC to 09:40 UTC on May 11, Search, Ingest and EIS functionality may have been unavailable. The root cause of this issue has been identified and resolved - we are currently monitoring, and expect no further impact.

This issue is now resolved. Email delivery has been successful with no monitored issues.

A solution has been implemented, and email delivery has resumed. We are continuing to track the situation closely and will provide another update once considered resolved.

We are currently investigating reports that some customers may be facing issues with email alerts.

This issue has now been resolved.

This issue has now been resolved and we are continuing to monitor the system.

We have identified and are working to mitigate an issue which is causing delayed AutoOps metrics for customers in AWS us-east-1.

The system has recovered and functionality has returned to normal.

We are continuing to see signs of stabilization and monitoring as the system recovers, but metrics visualizations in the Cloud console remains impacted until recovery is complete. We will provide a further update in 1 hour, or when there is a change in status.

Our investigation is ongoing.  We continue to see early signs of stabilization, but metrics visualizations in the Cloud console remain impacted.  We will provide a further update in 1 hour, or when there is a change in status.

Our investigation is ongoing. Some early signs of stabilisation have been observed, but metrics visualizations in the Cloud console remain impacted. We will provide a further update within 30 minutes.

Some users are seeing missing metrics visualizations in the Cloud console due to a disruption in metric data ingestion affecting deployments in the us-east-1 (US East) region. Some recent metric data may not appear in charts or monitoring views. We are actively investigating and will provide another update within 30 minutes.

The connectivity issues affecting a subset of customers in our AWS EU West (Paris) region have been resolved. Failed probes recovered at 11:36 UTC following remediation of an issue with our underlying cloud infrastructure provider. We are no longer observing any elevated error rates or latency in the region. We apologise for any inconvenience caused and will conduct a post-incident review.

Our monitoring system reports that AWS EU West 3 (Paris) region ingress layer traffic has recovered to normal levels as of 11:36 UTC and our SLO alerts have resolved. We are continuing to monitor and will update once we are confident the issue is fully resolved.

We are continuing to work on a fix for this issue.

We are currently investigating connectivity issues affecting a subset of customers in our AWS EU West 3 (Paris) region. Some requests may be experiencing elevated latency or failures. Our team is actively investigating, and we are working with our cloud infrastructure provider on the underlying issue. Other regions are not affected at this time. We will provide updates as the situation develops.

An incident with an upstream service provider has been resolved, and access to the model is now restored.

Errors are coming from the provider API (Google). The incident has been escalated to them, and we are still waiting for a response.

We're seeing elevated 5xx error rates for the Gemini Embedding v1 model in EIS. The following default inference endpoint is affected: - .google-gemini-embedding-001 We're investigating and will update again in 2 hours or if there's a change in status.

We have successfully deployed a fix for the PrivateLink hostname issue to the User Console. Customers who experienced incorrect PrivateLink URLs or connectivity issues with their deployments should now see correct hostnames. We apologize for the inconvenience.

We are still working on moving the fix to production as we experienced some testing issues.

We have merged a fix and are working on deploying it to production

A recent change to our Privatelink implementation resulted in the URLs reported by the deployment API being incorrect in some cases, causing connectivity issues for customers who relied on those URLs. We have identified the issue and are working on a fix.

We have confirmed no further impact from this incident, and are now marking it as resolved.

We have rolled out the fix and there should be no more customer impact

We have identified the issue and are working on a fix. We will update again in 3 hours or earlier.

We have identified that only PrivateLink customers are impacted and no other Hosted Cloud Deployments should see any issues.

We are aware of an issue when connecting to Kibana through the Elastic Cloud UI via SAML SSO, impacting hosted Cloud deployments. Our team is actively investigating. We will post an update to this status within the next hour.

Issue has been fixed and there should be no more customer impact

We have identified the problem and are working on a solution. We should have an update within the next 2-3 hours.

We are investigating an issue in our Synthetics service on us-east-4. Some customer monitor jobs may not run on their expected schedule. We will provide an update in an hour or earlier.

Endpoints are operating normally

We're seeing elevated 5xx error rates for the Claude Sonnet 4.5 model in EIS. The following default inference endpoints are affected: - .anthropic-claude-4.5-sonnet-chat_completion - .anthropic-claude-4.5-sonnet-completion - .gp-llm-v2-chat_completion - .gp-llm-v2-completion We're investigating and will update again in 2 hours or if there's a change in status.

AutoOps is back to full functionality in the AWS us-east-1 region and the incident has been resolved.

We have mitigated the issue, and AutoOps is back to full functionality in the AWS us-east-1 region. We will continue monitoring the signals from the region to ensure AutoOps remains fully functional, and will share another update once the issue is fully resolved.

We have identified the issue and applied mitigations to bring AutoOps in the AWS us-east-1 region back to functionality. Customer deployments may still be marked as inactive, and recent metrics may still not be available. We expect AutoOps to return to full functionality within the next hour. We will provide an update when one is available or within the hour, whichever comes first.

We are currently investigating an outage of AutoOps in AWS us-east-1 region. Customer deployments in the region may be marked as inactive and recent metrics may not be available. We will provide an update when one is available or within the hour, whichever comes first.

This issue is resolved. Customers are now able to create new Serverless projects in the GCP europe-west3 region

The engineering team is validating the fix to restore project creation in the GCP europe-west3 region. We will post another update in 2 hours or sooner if needed

We are aware of problems creating new Serverless projects in the GCP europe-west3 region. The engineering team has identified the problem and we are working on mitigating it. We will post the next updated in 2 hours.