I was able to reproduce this issue, but only with the UnreachablePeriod=1 setting in the server configuration file. Do you also have this parameter value reduced?

I also discovered another issue. The trigger transitions to the PROBLEM state only after an hour because the item on which the trigger is based has a throttling interval of 1 hour.

No, UnreachablePeriod is default (45), but that can still be right. I write "immediately" but more accurate is that trigger fired before I walked back. It was few minutes, but definitely less than half of {$SNMP.TIMEOUT}. Sorry for misunderstanding.

Yes, I originally wanted to report this second thing you mention that notification arrive late, thank you for reminding me.
Maybe it depends on when failure happens compared to discarding hearbeat? I actually don't know how min() and max() work with missing data. Is there documentation I can read?

Here is the documentation for the aggregation functions:

https://www.zabbix.com/documentation/current/en/manual/appendix/functions/aggregate

Thank you, but it says nothing about handling of missing data. Only thing I find is https://www.zabbix.com/documentation/current/en/manual/config/triggers#evaluation-period. If this is accurate, then it is easy:

Or put differently: Doing good triggers on items that discard/throttle is even harder than I expected.

The trigger expression is calculated at the moment when a new value is received. If there is no data within the calculated period (for example, when using time shift), the trigger is set to "Unknown" status with the corresponding error.

So it is more like interface fail is new value so it passes discard/throttle and causes calculation at time of fail:

By this you must create item & trigger, wait for 1st data, wait more than {$SNMP.TIMEOUT} but less than (throttling heartbeat minus UnreachablePeriod), then cause interface fail. This should calculate max() on window with only that red "fail" value and cause immediate trigger fire.