Alert when a log source goes quiet
Most detections fire when something bad arrives. Almost none fire when nothing arrives at all, which is the state an attacker is working towards.
Detection is usually built the same way. Something bad happens, it produces a log, a rule matches the log, an analyst sees an alert. Every part of that chain assumes events keep arriving.
An attacker who reaches SYSTEM or root does not have to defeat your rules. They can stop the events reaching you at all: kill the agent, remove the filter driver, disable the audit policy, unregister the tracing provider. Your console then shows exactly what a quiet night shows.
So build one detection that inverts the logic. For each log source, learn its normal volume by hour, and alert when it drops far below that for longer than its usual gap. Not zero events, since plenty of sources go quiet legitimately overnight. Far below its own baseline, at a time it is normally busy.
This is one of the highest signal to noise detections available, because healthy systems are boringly consistent about how much they talk. It also catches things that are not attacks at all: a failed agent upgrade, a full disk, a misapplied group policy, a forwarder pointed at the wrong collector. Every one of those is worth knowing about, and none of them would have raised an alert.
The uncomfortable question to take to your own environment: if a host stopped reporting right now, how long before anybody noticed?
CHECK YOURSELF
A server that normally sends 40,000 events an hour has sent none for six hours. No alerts have fired. What is the most defensible reading?
SHOW THE ANSWER
Something has stopped the telemetry, and that is itself an event to investigate
Why. Silence has two explanations: nothing happened, or you stopped being able to see. Those look identical on a dashboard, so the only safe reading is to treat unexplained silence as a finding until you have proved which one it is.