**CMK version: 2.3.0p34
**OS version: Rocky Linux 9.5
Any ideas why the Delay Notification rule is being ignored?


**CMK version: 2.3.0p34
**OS version: Rocky Linux 9.5
Any ideas why the Delay Notification rule is being ignored?


Hi,
I recently tested delayed notifications and they worked like a charm.
Did you activate the changes?
Does the Rule condition match the host?
Are you aware that you can delay Hosts and Services notifications and that these are two different rules?
KR Mimimi
In the images
Delay for both Hosts & Services is set at 5 mins.
Host alert is 15:45
Host notification 15:48
that is 3 mins?
Service alert is 15:39
Service notification is 15:41
that 2 mins
Yes changes are activated
Yes the rule matches
Yes, as you can see there is one rule for Hosts and another rule for Services
Global Setting > Logging of the core > Notification system: Debug
helped me to understand what was going on.
~/var/log/cmc.log
2025-06-23 14:14:12 [7] [notification helper 1654549] host "child_host": hard state change to DOWN
2025-06-23 14:14:12 [7] [notification helper 1654549] host "child_host": setting up, problem ID 5, delay 180sec
2025-06-23 14:14:12 [7] [notification helper 1654549] host "child_host": postponing, delayed notification
...
2025-06-23 14:17:12 [7] [notification helper 1654549] host "child_host": postponing, delayed notification
2025-06-23 14:17:13 [7] [notification helper 1654549] host "child_host": sending PROBLEM notification to its contacts
2025-06-23 14:17:13 [7] [notification helper 1654549] host "child_host": spooling notification to rule based notifications
Perhaps hard and soft states are interfering with the delay somehow?
What is normal check_interval and max check attempts ?
Sorry forgot to say this is the RAW version so no cmc log
check_interval is default no rules set.
max check attempts is 3 for both hosts and services.
Think I noticed something?
Is the notification created on the first alert,
or after the max check attempts?
Just checked the first 2 alerts in each are Soft, so no notification should be done,
but looking at the timings the notification is created on the first Soft alert?

per nagios documentation as andreas dug up last yearthe notification delay is calculated from the the first soft-state (the notification is of course only created on the hard state)
however this doesn’t fully explain it, as you would have 4 minutes in your service notification and 4m30s on your host notification example ![]()
however: you’re not alone with this inconsistent behaviour of the nagios core Frustrated by Inconsistent Notification Delays
Thanks all
That seems to have fixed the Delay Notifications
A recap, the rules I have set:
Maximum number of check attempts for host, mine is set to 3.
Retry check interval for host checks, mine is set 1 minute.
Delay host notifications, mine is now set to 3 minutes.
Maximum number of check attempts for service, mine is set to 3.
Retry check interval for service checks, mine is set to 1 minute.
Delay service notifications, mine is now set to 3 minutes.
Only one tip here - if you use delay notifications i would recommend not to use check attempt settings and vice versa.
Only one of these two settings should be used. then it is more clear what happens.
With Nagios core there are some more inconsistencies existing like a service problem triggers and immediate host check. This will interfere with the number of host check settings if you use the host check attempts.
agreed, use one of them and, while the delay is in minutes/hours which seems easier, I’d recommend to use the maximum check attempts, because this way you have soft and hard states which you can use to filter in the “Alert Statistics” view + any problem views to filter only for hard states.
If you use notification delays, I’m not aware of filtering for only alerts that would/have also create(d) a notification.
Thanks
I have disabled the check attempts rules