Trigger with dependency fires after parent trigger recovers

[aeb]

Hi,

I am trying to to debug an issue where an ICMP down trigger with a dependency of another hosts ICMP down trigger fires in the moment the parent trigger recovers, even if the condition of the dependent trigger is not met for a couple of iterations.
I've also tried to implement the solution from here: https://www.zabbix.com/forum/zabbix-...886#post481886
But that just makes it more weird.

Given this trigger action:

Details                                                           Start in      Duration
Send message to user groups: Zabbix administrators via all media  00:01:30      Default

Parent device "switch" has a trigger with problem and recovery expression:

Problem: max(/switch/icmpping,#3)=0
Recovery: min(/switch/icmpping,#3)=1

Child device "server" has a trigger with only a problem expression and is depending on the switches ICMP down trigger:

Problem: max(/server/icmpping,#3)=0

Now the switch goes down and Zabbix fires a trigger action for the problem and also for the recovery:

Parent device "switch":
2026-02-22 01:53:36 PM  Up (1)
2026-02-22 01:54:36 PM  Up (1)
2026-02-22 01:55:36 PM  Down (0)
2026-02-22 01:56:36 PM  Down (0)
2026-02-22 01:57:36 PM  Down (0)
2026-02-22 01:58:36 PM  Down (0)
2026-02-22 01:59:36 PM  Down (0) -> Problem Trigger Action fires: "Problem started at 01:57:36"
2026-02-22 02:00:36 PM  Down (0)
2026-02-22 02:01:36 PM  Up (1)
2026-02-22 02:02:36 PM  Up (1)
2026-02-22 02:03:36 PM  Up (1)  -> Recovery Trigger Action fires: "Problem has been resolved at 02:03:36"
2026-02-22 02:04:36 PM  Up (1)
2026-02-22 02:05:36 PM  Up (1)​

A problem trigger action is not fired for the dependent server. This is what I want and until here everything is how I expected it to be.
But after the parent device recovers, the problem trigger does fire for the child device, only to recover shortly afterwards, even though it has been up again for a few check iterations:

Child device "server"
2026-02-22 01:53:27 PM Up (1)
2026-02-22 01:54:27 PM Up (1)
2026-02-22 01:55:27 PM Down (0)
2026-02-22 01:56:27 PM Down (0)
2026-02-22 01:57:27 PM Down (0)
2026-02-22 01:58:27 PM Down (0)
2026-02-22 01:59:27 PM Down (0)
2026-02-22 02:00:27 PM Down (0)
2026-02-22 02:01:27 PM Up (1)
2026-02-22 02:02:27 PM Up (1)
2026-02-22 02:03:28 PM Up (1) -> Problem Trigger Action fires: "Problem started at 01:57:27"
2026-02-22 02:04:27 PM Up (1) -> Recovery Trigger Action fires: "Problem has been resolved at 02:04:27"
2026-02-22 02:05:27 PM Up (1)
​

Edit: I'm on Zabbix 7.4.2.
Does anyone have an idea why that's happening?

Thank you and all the best,
aeb

[kyus]

Your trigger on "server" fired before the trigger on "switch". The way dependencies work is: If trigger A depends on trigger B, when trigger B is in PROBLEM state, trigger A won't be evaluated nor will any actions be executed for the dependent trigger (A).

So in "server" Problem started at 01:57:27. Then in "switch" Problem started at 01:57:36.
Since your action has a 01:30 delay to send notifications, the dependency of "server" made it not start the action.
After your "switch" trigger was back in "OK" state at 02:03:36, the action from the "server" alert was evaluated and the notification was sent, and right after that, the trigger itself was evaluated when the "server" ICMP Ping item got a new value at 02:04:27 and the issue was resolved.

P.S.: I feel like this text is a bit confusing, but I hope it helps, anyways, for more detailed information you can check: https://www.zabbix.com/documentation...s/dependencies

[aeb]

Hi kyus,

thank you for your answer.
So the trigger for server fired at 01:57:27, then Zabbix started the notification action, which has a delay of 01:30. But after that delay passed, no massage was sent. From my understanding Zabbix would evaluate the trigger again after that delay of 01:30 to see if the state is still "problem". Since it did not send the message, the trigger state was not problem anymore, due to the dependency. Is that correct so far?
Or did Zabbix put the notification action on some kind of "hold" instead of discarding it after 01:30?

All the best,
aeb