# Elasticsearch monitoring tool - A chrome extension

**URL:** <https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969>\
**Category:** Community Ecosystem\
**Created:** [August 4, 2026, 2:38pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969 "2026-08-04T14:38:26Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![Musab\_Dogan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/musab_dogan/32/70691_2.png) [@Musab\_Dogan](https://discuss.elastic.co/u/Musab_Dogan)\
**Post date:** [August 4, 2026, 2:38pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/1 "2026-08-04T14:38:26Z")

</div>

Hey guys,

I've been debugging Elasticsearch clusters for years, and I got tired of jumping between `_cat` APIs, and terminal tabs just to check cluster health. So I built a lightweight [Chrome extension](https://chromewebstore.google.com/detail/elasticsearch-performance/eoigdegnoepbfnlijibjhdhmepednmdi) that surfaces the metrics I actually care about right from the browser toolbar. No agents, no setup overhead.

I'm sharing some of the metrics and insights below.

- indexing rate/latency & search rate/latency
- cluster status
- node stats
- JVM heap
- Active HTTP traffic
- long running tasks (reindex, update by query, etc)
- Slow search detection (with auto collect and profile aka. diagnose)

It's called **Searchali Monitoring** (Elasticsearch Performance Monitoring) and I'd genuinely love feedback from people who live in ES clusters daily. Happy to answer questions or take feature requests here.

🔗 [https://www.searchali.com/monitoring](https://www.searchali.com/monitoring)

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/3/5/35b4639efdf9794592e8523b933f4e8ce3f2ac34.jpeg)

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 5, 2026, 2:22am UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/2 "2026-08-05T02:22:30Z")

</div>

Ive installed it and the first thing which I note is that for every indicie it gives you an index rate and search rate per second so you can immediately see where data is going etc very quickly. I haven't found this in elasticsearch/kibana GUI anywhere but I'm a beginner in this space so may be somewhere. Anyway this is good.

---

<div class="post-metadata">

**Author:** ![Musab\_Dogan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/musab_dogan/32/70691_2.png) [@Musab\_Dogan](https://discuss.elastic.co/u/Musab_Dogan)\
**Post date:** [August 5, 2026, 11:23am UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/3 "2026-08-05T11:23:20Z")

</div>

Thank you so much for your feedback @geoffrey. I'm glad to hear you like the product.

indexing rate/latency and search rate/latency metrics also available in stack monitoring and AutoOps, but you should install an agent. Also in stack monitoring you should keep the data on your own cluster.

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 9, 2026, 3:07pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/4 "2026-08-09T15:07:31Z")

</div>

I notice in the screen for SHARD information that it is trying to display a fixed number of indicies irrespective of screen width. This means you can end up doing a lot of scrolling left and right on each page of indicie information. If it was able to dynamically determine how many indicies it can display (with no left-right scroll bar needed) I reckon this would be better as you now only have to only move pages forward and back.

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/c/3/c34a3ba5c826bb39d0c954bc6506b80b1c23cddf.png)

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 9, 2026, 9:55pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/5 "2026-08-09T21:55:32Z")

</div>

Hi @Musab_Dogan

I see in the p0 and r0 boxes you colour the background based on activity on the indicie in question. I would say that it is quite hard to pick this background colour up. If you used a bit different colour for the background it would probably be more noticeable. When in dark mode the colour is very similar to the background anyway.

This may be because I have too little index activity to show your colour intentions well.

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/3/9/396e73bb413212337555829693ab8efa6948d8c8.png)

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 9, 2026, 9:56pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/6 "2026-08-09T21:56:27Z")

</div>

Were you going to do this monitoring tool for edge browser ?

---

<div class="post-metadata">

**Author:** ![Musab\_Dogan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/musab_dogan/32/70691_2.png) [@Musab\_Dogan](https://discuss.elastic.co/u/Musab_Dogan)\
**Post date:** [August 10, 2026, 12:39pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/7 "2026-08-10T12:39:36Z")

</div>

hmm, good idea to make the colour more appeared. I'll check that. Thanks for your feedback.

Regarding to adding the extension to edge browser, it's on the roadmap. Whenever I saw a real potential in edge browser I'll add it. Just fyi, the number of users is less than %10 when you compare the chrome users 🙂

If you like the product, I'd love to get your feedback chrome webstore too: [https://chromewebstore.google.com/detail/elasticsearch-performance/eoigdegnoepbfnlijibjhdhmepednmdi/reviews](https://chromewebstore.google.com/detail/elasticsearch-performance/eoigdegnoepbfnlijibjhdhmepednmdi/reviews)

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![Musab\_Dogan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/musab_dogan/32/70691_2.png) [@Musab\_Dogan](https://discuss.elastic.co/u/Musab_Dogan)\
**Post date:** [August 10, 2026, 12:50pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/8 "2026-08-10T12:50:33Z")

</div>

> [@geoffrey](#):
>
> I notice in the screen for SHARD information that it is trying to display a fixed number of indicies irrespective of screen width. This means you can end up doing a lot of scrolling left and right on each page of indicie information. If it was able to dynamically determine how many indicies it can display (with no left-right scroll bar needed) I reckon this would be better as you now only have to only move pages forward and back.

Agreed. I fixed it at 7 indices per page. thanks for detailed feedback. It'll be available in the next version. which is 2.2.0

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/e/f/ef655cf175e08191ef9884ad6dd22af148a9ffd4.jpeg)

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 11, 2026, 9:46pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/9 "2026-08-11T21:46:11Z")

</div>

Hi @Musab_Dogan,

In regards to the CLUSTER stats it does a nice little summary of the transforms but in the description field it adds "data\_frame\_" to the beginning of the names of the transforms. This means that the identification of which transform is being referenced is not immediately obvious - you need to hover over the description to get the full name:

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/0/a/0aa06c71c810ff0330a449f3439a7ce3025ddbf2.png)

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 13, 2026, 4:52am UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/10 "2026-08-13T04:52:53Z")

</div>

I used to be a chrome user for quite some time but 2 years ago changed to edge. This was in part because of the RAM consumption of chrome. I reckon the edge of today uses less RAM than chrome and i dont have issues with any websites with edge.

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 16, 2026, 3:51am UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/11 "2026-08-16T03:51:47Z")

</div>

When I go into the TRAFFIC tab it initially appears to display network communications along the lines I would have expected:

 ![Screenshot 2026-08-16 115523](https://us1.discourse-cdn.com/elastic/original/3X/5/c/5c900b02df42fc219a4fc914c65abf06e02006c3.jpeg)

Once it has displayed this for more than 30 seconds all the communicating nodes on the right appear to disappear into the heading QUIET IPS. Typically it drops down to just one device showing as communicating:

 ![Screenshot 2026-08-16 115534](https://us1.discourse-cdn.com/elastic/original/3X/3/4/34b00dbb59e255eadad8c92a6917fb14313540d8.jpeg)

The IPs that I know are communicating with the elastic servers never reappear. It is only when you go to another tab and then return to the traffic tab that you get another 30s of useful information. As a result of this behaviour it is not particularly useful.

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 28, 2026, 1:44am UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/12 "2026-08-28T01:44:49Z")

</div>

In your NODES tab the networking section can just say Incoming and Outgoing. The current wording of "Transport RX/s" seems unnecessary:

 ![image](https://us1.discourse-cdn.com/elastic/original/3X/4/8/4815631e17d1dae92d0b6260b51aefe3092d00ea.png)

I would just call it transmitted (or TX/s) and received (RX/s).

---

<div class="post-metadata">

**Author:** ![Musab\_Dogan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/musab_dogan/32/70691_2.png) [@Musab\_Dogan](https://discuss.elastic.co/u/Musab_Dogan)\
**Post date:** [August 28, 2026, 8:24pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/13 "2026-08-28T20:24:38Z")

</div>

Thanks a lot for great feedbacks @geoffrey. Let me answer it one by one.

1. **long running tasks** - the tool show the long running tasks include internal default transform tasks. the explanation, "data\_frame\_...." is coming from the \_tasks api call results. I'm planning to drop all internal tasks from long running tasks screen.

2. **browser extension** - Thanks a lot for your feedback about edge vs chrome. We will see the results 🙂 Whenever I reach 1k users in chrome I'll plan to implement edge/firefox extension, app, web, docker image.

3. **TRAFFIC tab -** (only works with Elasticsearch because OS doesn't have that information). For the initial request, the API call collect all endpoints and draw the picture. 30 seconds later, the tool send another API call and compare the metrics espcially the ``request_count``. If the `request_count` not changed the IP will be marked as passive that you can see at the bottom of the list. With the following message **Quiet · 49 IPs No requests in the last 60s. Hidden from the map to reduce noise.**

4. **Nodes =\> Transport RX/s** - You're right. The names updated to `Incoming (RX) | Outgoing (TX)` . It'll be available in the next version.

@geoffrey this is for your great feedbacks 💐 Thanks.

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [August 30, 2026, 9:14pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/14 "2026-08-30T21:14:21Z")

</div>

> [@Musab\_Dogan](#):
>
> 1. **TRAFFIC tab -** (only works with Elasticsearch because OS doesn't have that information). For the initial request, the API call collect all endpoints and draw the picture. 30 seconds later, the tool send another API call and compare the metrics espcially the ``request_count``. If the `request_count` not changed the IP will be marked as passive that you can see at the bottom of the list. With the following message **Quiet · 49 IPs No requests in the last 60s. Hidden from the map to reduce noise.**

OK thanks for that. I guess in light of this I wonder if it perhaps would be worthwhile having a dropdown where you can specify how long a connection needs to be quiet before being dropped. As it currently stands, the 30 seconds you get, is sufficiently small that you are looking at what is happening and then it all disappears. The dropdown will allow some level of control around how long you get to observe things before they clear.

Also, with these discussions, if I send I think it is 3 replies and get nothing back it prevents me from doing any other replies until someone else says something. I was not aware of this limitation but I have to say its another "rule" that is annoying.

Anyway, thanks for the changes done so far. I using it daily more for my understanding of elasticsearch & kibana which is great.

---

<div class="post-metadata">

**Author:** ![Musab\_Dogan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/musab_dogan/32/70691_2.png) [@Musab\_Dogan](https://discuss.elastic.co/u/Musab_Dogan)\
**Post date:** [September 1, 2026, 11:28am UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/15 "2026-09-01T11:28:35Z")

</div>

> [@geoffrey](#):
>
> OK thanks for that. I guess in light of this I wonder if it perhaps would be worthwhile having a dropdown where you can specify how long a connection needs to be quiet before being dropped. As it currently stands, the 30 seconds you get, is sufficiently small that you are looking at what is happening and then it all disappears. The dropdown will allow some level of control around how long you get to observe things before they clear.

The main idea for this extension is "real time monitoring and trouble shooting". But we can see the history from first click to extension to current view. I'll think about a dropdown for some control.

I was not aware of 3 replies rule 🙂 sorry for that, I missed your message. I didn't receive any update.

Happy to hear you are using daily. Let me know if you have any more quesitons.

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [September 23, 2026, 5:53pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/16 "2026-09-23T17:53:42Z")

</div>

Things is see have been getting done. It is looking good now I reckon.

---

<div class="post-metadata">

**Author:** ![Musab\_Dogan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/musab_dogan/32/70691_2.png) [@Musab\_Dogan](https://discuss.elastic.co/u/Musab_Dogan)\
**Post date:** [September 24, 2026, 10:25am UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/17 "2026-09-24T10:25:05Z")

</div>

Thanks a lot for your feedback. In the next release, probably in one or two week, I'll improve auto-complete capability for REST tab, similar to kibana devtools. These days, everybody create DSL queries by AI (of course including me 😃) but even if so, it should be tested in somewhere.

It'll be available in version 2.8.0

---

<div class="post-metadata">

**Author:** ![geoffrey](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/geoffrey/32/145088_2.png) [@geoffrey](https://discuss.elastic.co/u/geoffrey)\
**Post date:** [September 27, 2026, 6:01pm UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/18 "2026-09-27T18:01:59Z")

</div>

1. **long running tasks** - the tool show the long running tasks include internal default transform tasks. the explanation, "data\_frame\_...." is coming from the \_tasks api call results. I'm planning to drop all internal tasks from long running tasks screen.

I quite like the fact that the transforms are included. I have had a transform periodically stop and have used this to identify the failure. Given this is not the first transform that has failed on me it does make for a central place to check on these things as well.

Anyway - that my thoughts on it.

---

<div class="post-metadata">

**Author:** ![Musab\_Dogan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/musab_dogan/32/70691_2.png) [@Musab\_Dogan](https://discuss.elastic.co/u/Musab_Dogan)\
**Post date:** [September 28, 2026, 7:29am UTC](https://discuss.elastic.co/t/elasticsearch-monitoring-tool-a-chrome-extension/388969/19 "2026-09-28T07:29:15Z")

</div>

@geoffrey thanks for your feedback. Yes, I thought to remove the internal long running tasks too but can't be sure about if it's a good idea or not because it can include some features that can be stopped even if they internal tasks. At least, it's good to aware of it 🙂
