# How to configure alert hierarchy/levels in kibana

**URL:** <https://discuss.elastic.co/t/how-to-configure-alert-hierarchy-levels-in-kibana/87708>\
**Category:** Elasticsearch\
**Tags:** elastic-stack-alerting\
**Created:** [May 31, 2017, 9:51am UTC](https://discuss.elastic.co/t/how-to-configure-alert-hierarchy-levels-in-kibana/87708 "2017-05-31T09:51:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![magda](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@magda](https://discuss.elastic.co/u/magda)\
**Post date:** [May 31, 2017, 9:51am UTC](https://discuss.elastic.co/t/how-to-configure-alert-hierarchy-levels-in-kibana/87708/1 "2017-05-31T09:51:07Z")

</div>

Hi,

How to configure alert hierarchy/levels in Kibana?  
I need to:

1. visualization of the overiding/primary alarm –\> if I look at the list of alerts, I will see all of them marked red, but I want the system to notifiy me with the contents of the overiding/primary alarm. Meaning: trigger an alarm when an event occurs and thera are no N-overriding/primary events.

2. delay configruration -\> secondary alarms may appear before primary alarms, hence the need for delay

3. If alarm will be transfered, The system will have to handle it - different systems on different levels - the simplest  
will set possibility to turn off the alarm through setting status for such alert as "during operation" or "fixed",  
such alarm will blink with colour but it won't make any sound. In such case, when our sub alerts will trigger before  
overriding alerts - those will have to be supported. How it is in the kibana? Can I get a sound signal?

Regards,  
Magda

---

<div class="post-metadata">

**Author:** ![shaunak](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/shaunak/32/6643_2.png) [@shaunak](https://discuss.elastic.co/u/shaunak)\
**Post date:** [June 8, 2017, 7:56am UTC](https://discuss.elastic.co/t/how-to-configure-alert-hierarchy-levels-in-kibana/87708/2 "2017-06-08T07:56:33Z")

</div>

Hi @magda,

Watcher does not have a built-in way of expressing dependencies between watches. As such the Watcher UI in Kibana x-pack cannot understand and visualize dependencies between watches.

Currently the closest way to model a dependency like "watch A depends on watch B" would be for watch A to use the `search` input to retrieve watch B's latest execution result from the `.watcher-history-*` indices, and lookup its status (or some other field, depending on the nature of the dependency). Then watch A could respond appropriately in its next execution. However, in this model, the UI cannot know for sure that watch A is attempting to express a dependency on watch B, and hence cannot visualize it either.

Hope that makes sense.

Shaunak

---

<div class="post-metadata">

**Author:** ![magda](https://avatars.discourse-cdn.com/v4/letter/m/dc4da7/32.png) [@magda](https://discuss.elastic.co/u/magda)\
**Post date:** [June 8, 2017, 9:30am UTC](https://discuss.elastic.co/t/how-to-configure-alert-hierarchy-levels-in-kibana/87708/3 "2017-06-08T09:30:28Z")

</div>

Ok,  
thank you for the reply!

Magda

---

<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:** [July 6, 2017, 9:30am UTC](https://discuss.elastic.co/t/how-to-configure-alert-hierarchy-levels-in-kibana/87708/4 "2017-07-06T09:30:30Z")

</div>

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