Loading status…
Elastic status · Developer Tools · checked (46s ago)
Also searched as Elasticsearch, Elastic Cloud, Kibana.
Partly — Elastic is up but running slower than usual (Partial System Outage).
According to Elastic's official status page, Elastic was reporting “Partial System Outage” when isuptime last checked at . Over the last 30 days, Elastic's feed reported no outage in 99.99% of our checks.
isuptime cannot fix Elastic, and neither can you. These are the things that are actually worth doing until it comes back.
Everything above is read from Elastic's own status feed. This is what other visitors are saying in the last 24 hours — useful when the feed is green and you are still stuck, and never used to change the status above.
Nobody has reported Elastic in the last 24 hours. Yours would be the first.
Reports are anonymous counts and are kept for 24 hours, then deleted. No account, no message, nothing stored about who reported. One report per service per hour, changeable until the hour is out.
Elastic runs Elasticsearch, Kibana, Logstash and Beats, and hosts them as Elastic Cloud across AWS, Google Cloud and Azure — search, log analytics, observability and security workloads.
Elastic's status page is one of the most finely subdivided anywhere: it lists every combination of product, cloud provider and region as its own component, which runs into the hundreds. That granularity distorts the aggregate indicator badly — a problem in a single AWS region can leave the headline reading “Partial System Outage” for weeks while the overwhelming majority of components are healthy. isuptime weighs the indicator against the share of components actually affected rather than repeating the headline, which is why Elastic often reads as operational here while its own page shows amber.
isuptime reads this feed on a schedule and reports what it says — how that works, in detail.
One bar per day. Each shows the share of that day's checks where Elastic's own status feed reported no outage — degraded counts as no-outage. Days with no bar are days isuptime recorded no checks, not days Elastic was down.
8 other services isuptime tracks were also reporting a problem as of the same check, 46s ago. They are checked on one schedule, so the timing is comparable — but overlapping in time does not mean they share a cause.
Each point is one check of Elastic's status endpoint.
Elastic has published 50 incidents in the last 12 months, the 20 most recent shown here. Only what Elastic posted itself — not every problem users hit.
resolved · Sep 23, 02:04 PM (11h ago)
resolved · Sep 17, 03:50 PM (6d ago)
resolved · Sep 16, 01:17 PM (7d ago)
resolved · Sep 12, 11:21 PM (11d ago)
resolved · Sep 10, 01:30 AM (14d ago)
resolved · Sep 9, 08:44 PM (14d ago)
resolved · Sep 2, 12:04 AM (22d ago)
resolved · Sep 1, 03:18 PM (22d ago)
monitoring · Sep 1, 08:16 AM (22d ago)
resolved · Aug 27, 05:11 PM (27d ago)
resolved · Aug 20, 08:22 PM (34d ago)
resolved · Aug 20, 12:48 PM (34d ago)
resolved · Aug 14, 09:22 AM (40d ago)
resolved · Aug 13, 08:32 AM (41d ago)
resolved · Aug 13, 03:57 AM (41d ago)
resolved · Aug 6, 05:41 PM (48d ago)
resolved · Aug 5, 10:59 PM (49d ago)
resolved · Jul 21, 02:24 PM (64d ago)
resolved · Jul 21, 01:45 PM (64d ago)
resolved · Jul 21, 09:36 AM (64d ago)
Check which cloud provider and region your deployment is actually in, since that is the level at which Elastic incidents happen. A cluster in yellow or red health is a shard allocation problem in your own deployment, not an Elastic Cloud outage. Hitting the disk watermark puts indices into read-only mode, which presents as writes mysteriously failing.
