Could it be something network related? Like the host not able to communicate with the server so it just stops trying?

You have to definitively determine where the blockage is. Run with --verbose=1 flag and see if the scheduler is still running queries. Add --tls_dump=1 flag to see that http communication is still continuing. Also, note that osquery only sends differential results by default, so if there is no change from previous results, no results are sent. So perhaps add something to your schedule that runs every minute or so that has diffs like

SELECT total_seconds FROM uptime

I am running

--vebose

on all my hosts and nothing seems out of the ordinary. Also there is no need for me to use test queries because I am judging whether a host is communicating is with Kolide's last seen on each host

Abrupt changes to osqueryd workers could be a result of watcher.cpp. Thus, the watcher daemon could have stopped the process if memory or cpu utilization reached threshold.

Running on windows... I'll try running with

--disable_watchdog

and see if that helps

I enable

tls_dump

via CLI when debugging.

sudo /usr/bin/osqueryd --flagfile [...] --config_path [...] --verbose --tls_dump

how can you run

--verbose

with all the

Failed to open handle to process <num> with 5

coming up all the time?

I wonder if the following PR fixes your issue: https://github.com/osquery/osquery/pull/5919/files

no, you will still see some of those log lines for protected processes