Skip to main content

Is Elastic Cloud Down?

No — Elastic Cloud is up

Reachable from all 8 checked regions

Average response time: 268ms

Last checked · checks run every 6 hours

Official status page: https://status.elastic.co

Connectivity disruption for AWS Bahrain (me-south-1)

major identified

Update — Incident ongoing. AWS Bahrain (me-south-1) has been removed from new deployment selection on cloud.elastic.co. Existing deployments remain inaccessible due to the AWS infrastructure disruption, with no recovery timeline provided by AWS. Assume the region is unavailable for the foreseeable future. For assistance, please open a case in our Support portal (https://support.elastic.co) or email support@elastic.co.

Components the vendor reports as affected: Elasticsearch connectivity: Azure azure-westus2 Degraded Performance AWS EC2 Health: me-south-1 Major Outage Azure Infrastructure Health Degraded Performance Kibana connectivity: Azure azure-westus2 Degraded Performance Snapshot Storage Infrastructure (S3): me-south-1 Major Outage Elasticsearch connectivity: GCP asia-south1 Degraded Performance Azure Infrastructure health: azure-westus2 Degraded Performance Deployment orchestration (Create/Edit/Restart/Delete): AWS me-south-1 Major Outage APM connectivity: Azure azure-westus2 Degraded Performance APM connectivity: AWS me-south-1 Major Outage AWS Infrastructure health: me-south-1 Major Outage Elasticsearch connectivity: AWS me-south-1 Major Outage Kibana connectivity: AWS me-south-1 Major Outage

A component listed here does not necessarily mean a full outage — large providers routinely report maintenance on individual locations. It only affects the verdict above when the vendor marks it major or critical and our own checks also saw Elastic Cloud fail from enough regions to rule out probe noise.

Elastic Cloud uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
234ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 10 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

10-day clean streak
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: no data
Jul 29: no data
Jul 30: no data
Jul 31: no data
Aug 1: no data
Aug 2: no data
Aug 3: no data
Aug 4: no data
Aug 5: no data
Aug 6: no data
Aug 7: no data
Aug 8: no data
Aug 9: no data
Aug 10: no data
Aug 11: no data
Aug 12: no data
Aug 13: no data
Aug 14: 100.00% uptime, 16 checks, 1 incident
Aug 15: 100.00% uptime, 32 checks, 1 incident
Aug 16: 100.00% uptime, 31 checks, 1 incident
Aug 17: 100.00% uptime, 32 checks, 1 incident
Aug 18: 100.00% uptime, 32 checks, 1 incident
Aug 19: 100.00% uptime, 32 checks, 1 incident
Aug 20: 100.00% uptime, 32 checks, 1 incident
Aug 21: 100.00% uptime, 32 checks, 1 incident
Aug 22: 100.00% uptime, 32 checks, 1 incident
Aug 23: 100.00% uptime, 40 checks, 1 incident
Jul 25 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
170ms
DNS 0ms TCP 7ms TLS 4ms TTFB 156ms
arn
179ms
DNS 0ms TCP 0ms TLS 3ms TTFB 167ms
bom
993ms
DNS 0ms TCP 1ms TLS 4ms TTFB 254ms
cdg
149ms
DNS 0ms TCP 1ms TLS 4ms TTFB 142ms
dfw
234ms
DNS 0ms TCP 0ms TLS 8ms TTFB 56ms
ewr
91ms
DNS 0ms TCP 1ms TLS 4ms TTFB 81ms
fra
167ms
DNS 0ms TCP 1ms TLS 4ms TTFB 153ms
gru
202ms
DNS 0ms TCP 3ms TLS 5ms TTFB 188ms
iad
129ms
DNS 0ms TCP 7ms TLS 10ms TTFB 96ms

What Elastic Cloud does

Elastic Cloud is the managed version of Elasticsearch and Kibana, run by Elastic across AWS, Azure and Google Cloud in dozens of regions. Teams use it for application search, log and metrics analytics, and security monitoring. Because it often holds the very logs used to debug an incident, an Elastic outage tends to arrive at the least convenient moment.

What an outage looks like

Search queries time out or return partial results with shard failures. Kibana loads but its dashboards stay empty, or it cannot reach the cluster at all. Ingest backs up, so logs and metrics arrive late or stop arriving, leaving a visible gap in dashboards. Deployment changes such as scaling or upgrading stall in the console.

What to do about it

Check status.elastic.co, which reports each cloud provider and region separately alongside shared services such as the console, deployment orchestration and the Docker registry. Find your deployment's provider and region rather than reading the top of the page. Whether a gap in dashboards means data was lost depends on whether your shipper buffers, so check the agent before concluding either way.

Is it down for everyone, or just you?

If this page says Elastic Cloud is up but it is not loading for you, the problem is between you and them. Run a check against any URL from all 18 regions to find out where it breaks.

Test it yourself

Related services

Elastic Cloud outage FAQ

Is my deployment affected or just the console?
Elastic tracks the cloud console, deployment orchestration and the regional infrastructure as separate components. A console outage stops you making changes while leaving search and ingest working normally. Query the cluster endpoint directly to establish whether the data path is healthy, since the console is the surface most likely to fail on its own.
Did I lose logs during the outage?
That depends on the shipper rather than on Elastic. Agents that buffer to disk resend once the cluster is reachable, so the gap fills in afterwards. Agents that drop what they cannot send leave a permanent hole. This is worth establishing before an incident, because the answer decides whether a dashboard gap is a display problem or missing evidence.
Which region should I be watching?
The one your deployment runs in, named by provider and region on the status page, for example AWS Ireland or GCP Iowa. Elastic lists dozens of them and they fail independently, so the page often shows a major outage in one region while every other region is untouched. The heading alone will mislead you in both directions.
Why are searches returning partial results instead of failing?
Elasticsearch answers from the shards it can reach, so a fault affecting some shards produces incomplete results with a shard failure count rather than an outright error. Applications that ignore that count silently show users a partial answer as though it were complete. During an incident, treating any non-zero shard failure as a failed query is the safer reading.

How we measure this

  • We request Elastic Cloud's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Elastic Cloud publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Elastic Cloud goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required