The standard advice about monitoring is to measure what matters. Track error rates, latency, throughput, resource utilization. Set up alerts when these metrics cross thresholds. The theory is that if something important breaks, one of your metrics will move, and you’ll know.

The gap in this model is that it only captures commission — things the system did that it shouldn’t have, or did poorly. It systematically undercounts omission — things the system should have done but didn’t. A process that runs on a schedule and produces no output is invisible to most monitoring setups. A cache that stops refreshing looks the same as a cache that’s current. A background job that exits zero without doing any work appears identical to one that completed successfully. The metric stays flat. The alert never fires. The system appears healthy.

This distinction matters because omission failures are often more costly than commission failures. When a system produces a bad output, you usually find out quickly — downstream systems break, users complain, something throws an error. When a system produces no output, or stale output, the consequences are quieter: decisions get made on outdated information, coverage gaps silently widen, state drifts in ways that are only apparent when you go looking for them.

The fix requires a different kind of monitoring: not just “did this thing run” but “did this thing produce the expected output.” For a scheduled job, that means verifying not just that it executed but that it completed successfully and produced a result — and ideally, that the result has the right shape. For a cache, it means tracking the age of the cached value, not just whether the cache was hit. For a background pipeline, it means tracking output counts and checking them against expected throughput, not just watching for exceptions.

What this often looks like in practice: a “heartbeat check” that’s separate from the process itself. The process runs and updates a timestamp when it completes successfully. A separate check verifies that the timestamp is recent enough. If the process runs but fails before completing, the timestamp doesn’t update, and the check catches it. If the process doesn’t run at all, same result. The check doesn’t care about the process’s internal state — it only cares about the output it’s supposed to produce.

The asymmetry between commission and omission errors is also why “the dashboards look fine” is a weak signal. Dashboards measure what they measure. If they’re not measuring output freshness, or completion counts, or result validity, a system can fail silently for a long time while every chart stays green. The question isn’t whether your monitoring is sophisticated — it’s whether it’s measuring the right thing. And for periodic systems, the right thing is usually “did this produce what it was supposed to produce, recently enough to be useful.”