pfSense

I don't need support. I have fixed the issue for me by modifying /etc/rc.gateway_alarm (which by the way unconditionally issues a filter reload, so no clue where in your case the code exits early before that reload, there is exactly one way to exit early in that script and that's obviously not reached in your case either). Your choice if you want to fix it for others aswell, but I am sure professional customers won't be amused if they find this bug report one day cause they are having the same issues and see that you don't seem to care, but that's not my problem.

Logs are clear in my case (read from bottom to top):

Mar 5 16:48:08    check_reload_status    412    Reloading filter
Mar 5 16:48:08    check_reload_status    412    Restarting OpenVPN tunnels/interfaces
Mar 5 16:48:08    check_reload_status    412    Restarting IPsec tunnels
Mar 5 16:48:08    check_reload_status    412    updating dyndns XXXX
Mar 5 16:48:08    rc.gateway_alarm    24321    >>> Gateway alarm: XXXX (Addr:XXXX Alarm:1 RTT:803.356ms RTTsd:512.895ms Loss:34%)

That's for a gateway which is set to "force as inactive", so dpinger is still monitoring but it's being always seen as inactive (or at least it should).

Maybe the UI is just misleading here: There is an option to disable the gateway monitoring action (which states that it forces the gateway active, so I don't select that as that's not what I want) and there's an option to force the gateway to be down (which I selected as that's what I want). However, that option does cause the script to be called and causes the filter reload.

Maybe a dropdown to "Force state" would be better which can select between "Force up", "Force down" and "Use real state". There's also the option to "Disable Gateway monitoring", if that's selected the "Use real state" option should not be available. Or the dropdown get's the options "Force up and disable monitoring" and "Force down and disable monitoring" aswell, so all those 3 checkboxes are turned into a single dropdown with 5 options.