Skip to main content
Elastic Cloud logo

Is Elastic Cloud Down?

No — Elastic Cloud is up

Reachable from all 8 checked regions

Average response time: 420ms

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: AWS EC2 Health: me-south-1 Major Outage Snapshot Storage Infrastructure (S3): me-south-1 Major Outage Deployment orchestration (Create/Edit/Restart/Delete): AWS me-south-1 Major Outage 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
345ms
Avg response, 30 days

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

30-day history

61-day clean streak
Sep 14: 100.00% uptime, 32 checks, 1 incident
Sep 15: 100.00% uptime, 32 checks, 1 incident
Sep 16: 100.00% uptime, 32 checks, 1 incident
Sep 17: 100.00% uptime, 32 checks, 1 incident
Sep 18: 100.00% uptime, 32 checks, 1 incident
Sep 19: 100.00% uptime, 32 checks, 1 incident
Sep 20: 100.00% uptime, 32 checks, 1 incident
Sep 21: 100.00% uptime, 32 checks, 1 incident
Sep 22: 100.00% uptime, 54 checks, 1 incident
Sep 23: 100.00% uptime, 32 checks, 1 incident
Sep 24: 100.00% uptime, 32 checks, 1 incident
Sep 25: 100.00% uptime, 32 checks, 1 incident
Sep 26: 100.00% uptime, 32 checks, 1 incident
Sep 27: 100.00% uptime, 32 checks, 1 incident
Sep 28: 100.00% uptime, 32 checks, 1 incident
Sep 29: 100.00% uptime, 32 checks, 1 incident
Sep 30: 100.00% uptime, 32 checks, 1 incident
Oct 1: 100.00% uptime, 31 checks, 1 incident
Oct 2: 100.00% uptime, 32 checks, 1 incident
Oct 3: 100.00% uptime, 32 checks, 1 incident
Oct 4: 100.00% uptime, 32 checks, 1 incident
Oct 5: 100.00% uptime, 32 checks, 1 incident
Oct 6: 100.00% uptime, 32 checks, 1 incident
Oct 7: 100.00% uptime, 32 checks, 1 incident
Oct 8: 100.00% uptime, 32 checks, 1 incident
Oct 9: 100.00% uptime, 32 checks, 1 incident
Oct 10: 100.00% uptime, 32 checks, 1 incident
Oct 11: 100.00% uptime, 32 checks, 1 incident
Oct 12: 100.00% uptime, 32 checks, 1 incident
Oct 13: 100.00% uptime, 32 checks, 1 incident
Sep 14 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.

jnb
1503ms
DNS 51ms TCP 170ms TLS 173ms TTFB 708ms
lax
121ms
DNS 63ms TCP 2ms TLS 4ms TTFB 102ms
lhr
370ms
DNS 53ms TCP 1ms TLS 8ms TTFB 200ms
nrt
221ms
DNS 114ms TCP 1ms TLS 3ms TTFB 212ms
ord
190ms
DNS 122ms TCP 0ms TLS 3ms TTFB 175ms
sin
258ms
DNS 9ms TCP 0ms TLS 3ms TTFB 215ms
sjc
77ms
DNS 31ms TCP 1ms TLS 4ms TTFB 62ms
syd
623ms
DNS 7ms TCP 0ms TLS 3ms TTFB 152ms

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 up to 17 cities across three 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 — the most recent check ran from 8 of them.
  • 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 up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required