BTMichel

**Update** We have faced the exact error again today, where a Recovery Notification was sent out, even though there was no problematic hard state reached before:  In this screenshot...

@Al2Klimov > You could also try to disable IDO HA, so that both nodes write to database, as a workaround. https://icinga.com/docs/icinga-2/latest/doc/06-distributed-monitoring/#high-availability-with-db-ido Thank you very much for your input on this...

Thanks for coming back to this topic @Al2Klimov and @yhabteab! 👍 @yhabteab we did actually wait for much longer than the default failover_timeout, since our external monitoring did alert about...

@yhabteab unfortunately, because of log rotations and because the last time this issue occured was *(fortunately)* in april, I do not have those specific logs at hand anymore. I can...

@yhabteab thanks for the analyzing the issue! So there is actually a bug in the IDO HA feature. > I don't know if we're going to change that now. By...

Just a heads up, since this feature would be greatly appreciated 🚀 I think a check of the scope would be sufficient, since the properties of the certificates would be...

We are also negatively affected by this issue after updating the plugins:  All our thresholds are now incorrect and would need manual configuration for each host according to socket...

We are also encountering this issue, lots of timeouts since we updated the icinga powershell framework. The only viable fix/workaround currently is a rollback to the previous version, which we...