# Alert status escalation

**URL:** <https://community.netdata.cloud/t/alert-status-escalation/6027>\
**Category:** Help\
**Tags:** cloud, configuration, agent, alerts, notifications\
**Created:** [November 27, 2024, 5:27pm UTC](https://community.netdata.cloud/t/alert-status-escalation/6027 "2024-11-27T17:27:35Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![car12o](https://yyz1.discourse-cdn.com/flex029/user_avatar/community.netdata.cloud/car12o/32/3515_2.png) [@car12o](https://community.netdata.cloud/u/car12o)\
**Post date:** [December 3, 2024, 4:41pm UTC](https://community.netdata.cloud/t/alert-status-escalation/6027/2 "2024-12-03T16:41:53Z")

</div>

Hello @Richard_Barrantes,

The configuration you shared is pretty close to what you desire, it just needs small changes.

If you want the alert to check on a time window you need change the query (`lookup` field) . Changing `delay` field would just delay the notification but the alert will still trigger for the average of the last 5min.

Since query a big time window is a heavy query, this also bypasses tiering and requests high resolution data from tier 0 (per second) not tier 1 (per min) or tier 2 per hour, we may want to do not check the alert that often (every 60s). Let’s run the alert check every 15min for example by changing the `every` field.

> <https://github.com/netdata/netdata/pull/16032>
>
> \##### Summary
> \<!--
> Describe the change in summary section, including rationale… and design decisions.
> Include "Fixes #nnn" if you are fixing an existing issue.
> \--\>
>  
> This PR forces the use of tier 0 when doing health queries. In some cases, e.g. when the lookup period is big, the query planer might pick another tier to execute the query. This could lead to unexpected results.
> 
> Of course this change can slightly affect cpu usage, but in same levels as when before tiering was introduced.
> 
> \##### Test Plan
> 
> \<!--
> Provide enough detail so that your reviewer can understand which test cases you
> have covered, and recreate them if necessary. If our CI covers sufficient tests, then state which tests cover the change.
> \--\>
> 
> Testing of general alert results. Will also be tested on a specific use case (large update\_every and big lookup).
> 
> \##### Additional Information
> \<!-- This is usually used to help others understand your
> motivation behind this change. A step-by-step reproduction of the problem is
> helpful if there is no related issue. --\>
> 
> \<details\> \<summary\>For users: How does this change affect me?\</summary\>
> \<!--
> Describe the PR affects users: 
> \- Which area of Netdata is affected by the change?
> \- Can they see the change or is it an under the hood? If they can see it, where?
> \- How is the user impacted by the change? 
> \- What are there any benefits of the change? 
> \--\>
> \</details\>

So the end result should be something like this:

```auto
template: Alerts_Inactive_Replication_Slots_6h
       on: Alerts.Inactive_Replication_Slots
   lookup: average -6h unaligned of Inactive
    units: slots
    every: 15m
     warn: $this >= 1
  summary: Inactive Replication Slots 6h
     info: Inactive Replication Slots 6h
       to: dba

```

Unfortunately it’s not possible to change the query AKA lookup to use a different time window, so for the 24h check we will need to create another alert.

```auto
template: Alerts_Inactive_Replication_Slots_24h
       on: Alerts.Inactive_Replication_Slots
   lookup: average -24h unaligned of Inactive
    units: slots
    every: 30min
     crit: $this >= 1
  summary: Inactive Replication Slots 24h
     info: Inactive Replication Slots 24h
       to: dba

```

Also, I see you have `charts` AKA `on` field and dimension AKA `lookup: average ... Inactive` with upper case letter, please confirm those are correct. Usually they are all lower case.

I hope this help you out.

---

_[View the full topic](https://community.netdata.cloud/t/alert-status-escalation/6027)._