# Watcher alert only on state transition (error / ok state)

**URL:** https://discuss.elastic.co/t/watcher-alert-only-on-state-transition-error-ok-state/243076
**Category:** Elasticsearch
**Tags:** elastic-stack-alerting
**Created:** [July 29, 2020, 2:40pm UTC](https://discuss.elastic.co/t/watcher-alert-only-on-state-transition-error-ok-state/243076 "2020-07-29T14:40:53Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![trigger-unhappy](https://avatars.discourse-cdn.com/v4/letter/t/ba8739/32.png) [@trigger-unhappy](https://discuss.elastic.co/u/trigger-unhappy)
#### Post date: [July 29, 2020, 2:40pm UTC](https://discuss.elastic.co/t/watcher-alert-only-on-state-transition-error-ok-state/243076/1 "2020-07-29T14:40:53Z")

</div>

I've read this [nice post](https://discuss.elastic.co/t/alert-when-okay/112707) on how you could possibly set up Watcher to trigger an action only when a watch change state (similar to how cloudwatch does it with events). I'd love to set something like that up to avoid spamming my alert channels and also get some feedback when things go back to normal (I once had a situation when the whole cluster was not doing very well and alert were not sent as a result).

As I understand the general idea is:

- have my watches check whatever condition I check already
- add chained input with watch history
- script the condition so that it doesn't only take the metric I look at into account but also watch history to prevent firing if the state is already "error"

Alternatively, would this be possible:

- I keep my current watches exactly as they are, but remove notification action
- add a new watch per each of the above that looks at state changes in watcher history and triggers action on state transition

Does that make sense? Is there a more up-to date version of how to set something like that up? I use 7.8 and it seems like index names changed a bit and debugging watcher is a nightmare, so some verified instructions would be appreciated.

---

<div class="post-metadata">

### Author: ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)
#### Post date: [August 3, 2020, 9:27am UTC](https://discuss.elastic.co/t/watcher-alert-only-on-state-transition-error-ok-state/243076/2 "2020-08-03T09:27:46Z")

</div>

Hey,

that sounds about right. One of the advantages of the first idea would be that a single watch cannot collide with another watch, that probably tries to clean things up, so I would probably go with that, despite being somewhat more complex.

With regards to better and easier debugging of watches: Take a look a [this blogpost](https://www.elastic.co/blog/watching-the-watches-writing-debugging-and-testing-watches) that I wrote a while ago - while the endpoints do not have the `_xpack` suffix anymore, most of this is still accurate.

if you have questions, just drop them in the forum 🙂

--Alex

---

<div class="post-metadata">

### Author: ![trigger-unhappy](https://avatars.discourse-cdn.com/v4/letter/t/ba8739/32.png) [@trigger-unhappy](https://discuss.elastic.co/u/trigger-unhappy)
#### Post date: [August 6, 2020, 8:05am UTC](https://discuss.elastic.co/t/watcher-alert-only-on-state-transition-error-ok-state/243076/3 "2020-08-06T08:05:53Z")

</div>

heh, this way to cumbersome to set up than it should be. [Debugging "painless"](https://www.elastic.co/guide/en/elasticsearch/painless/current/painless-debugging.html) is also everything but "painless". I'm wondering if watcher will continue to evolve or the latest improvements are the most we can expect...

---

<div class="post-metadata">

### Author: ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)
#### Post date: [August 12, 2020, 8:27am UTC](https://discuss.elastic.co/t/watcher-alert-only-on-state-transition-error-ok-state/243076/4 "2020-08-12T08:27:15Z")

</div>

See the following links regarding that topic and the new alerting framework within the Elastic Stack

> **[New alerting framework released for Observability, Security and the Elastic...](https://www.elastic.co/blog/introducing-the-new-alerting-framework-for-observability-security-and-the-elastic-stack)**
>
> We’re excited to announce a new alerting framework that delivers a first-class alerting experience natively within the SIEM, Uptime, APM, and Metrics applications as part of the Kibana 7.7 release and includes integrations to Slack, PagerDuty, and...

  

> **[Alerting in the Elastic Stack](https://www.elastic.co/blog/alerting-in-the-elastic-stack)**
>
> Watcher (our original suite of alerting features for Elasticsearch) was introduced back in 2015. Find out more about the Elastic Stack’s current alerting capabilities and the future vision: alerting everywhere, how to make sense of those alerts, and...

  

> **[Kibana Alerting: Alerts & Actions for Elasticsearch data | Elastic](https://www.elastic.co/what-is/kibana-alerting)**
>
> Monitor all of your alerts in one place inside Kibana with the alerting and actions framework for Elasticsearch. Detect changes and anomalies in your logging, APM, and SIEM data.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [September 9, 2020, 8:27am UTC](https://discuss.elastic.co/t/watcher-alert-only-on-state-transition-error-ok-state/243076/5 "2020-09-09T08:27:17Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
