Putting this here since it seems to make sense: your API is what 'tells' agents that an update is available - if an agent queries API, gets update-avail = TRUE - and then you don't see a check in... Please raise an alert. It 'could' be a device that legit went to sleep or offline at the same time, but in our experience that is so rare as to be a non-issue.

We've found plenty of agents that failed open with the latest code (v1.11->1.12) where we either had to manually start the service (and then it was OK, had 1.12 code) or something faulted and the service no longer starts; typically resolvable with uninstall/re-install (which REALLY should not be happening, but I don't see how you get around this unless you redo your self-update to split it into an isolated process)

We are still fairly new to DNSfilter, how are you finding out that you have these issues? We have datto rmm which I built a policy with powershell to install on the device if the service isn't running.. I haven't heard of any issues with users but also not really sure how to tell if we have one

Same issue here and we were on 1.8.2. The only fix from support was to run a powershell job they provided to uninstall/reinstall. Not a great fix for a large organization.

We see this as well periodically. We also have lots of agents that stop auto updating.

Same issue encountered by us and chat support asked us to upgrade the windows agent to 1.8.2 but the issue still persist of the agent stops working intermittently(3 tickets opened in the past for same issue). This is beating the purpose of having Roaming client agent available all the time to protect the endpoint. Even when the agent is down all the DNS request should always go through 127.0.0.2 irrespective of the agent availability so that we come to know of the agent not running but it is switching to router assigned DNS servers when the agent is down. Not cool since the product engineering should cover these scenarios and remediate it since leaving a risk unattended in cybersecurity is dangerous.

This isn't related to the feature request itself, but to the issues mentioned in the request. We encourage updating to the latest Windows roaming client version (1.8.2) if you are on an older version and experiencing issues. We have made many improvements that customers have provided positive feedback on - https://dnsfilter.canny.io/changelog/windows-roaming-client-182-auto-update-scheduled-for-monday-1024. If you're still having issues on the latest version, please submit a support ticket so we can further troubleshoot. We are focused on improving the experience and working through all issues that are being reported. Thank you for your help.

As a DNS MSP Partner we also experience this problem across the estate of computers we manage and monitor. It has been getting significantly worse of late.

We're also running into the issue where the windows roaming client stops filtering randomly and we have to restart it to get it working again. This has been a major issue