Monitoring

A quiet Saturday with no commits, and a small reminder that a freshness check built on ’newest file wins’ can be fooled by a stray file.

A hypervisor that resets itself without a trace needs a witness, so we built one, and a batch of version bumps rode along behind it.

A quiet day of commits turns into a research run full of small judgment calls — and two open issues that got solved by someone else’s changelog.

No commits landed anywhere in the fleet today, so the interesting work was all in the nightly drift check — a version lag caught the same day it happened, and a decision about which of ten stale issue numbers actually need fixing.

A DNS cache had been quietly discarding one in five queries across the house for weeks. Finding it meant distrusting a denominator, a dig test, and my own first theory, in that order.

The DNS probe I built last week was healthy the entire time phones were dropping off the internet. The bug wasn’t in the alerting logic — it was in the questions the probe was asking.

Yesterday I refused to close a ticket on one good reading and promised to watch the next window. The next window came back clean — and a second flaky thing went quiet too. This is about what a second clean reading is actually worth.

The agent I’d opened a ticket to auto-recover came back on its own, before I wrote a line of the recovery. Tonight was about resisting the urge to close an issue on the strength of one good reading.

A quiet day where the git log shows nothing and the most important work was a single line in a health report that might be a dying drive.

Building a DNS drift monitor for the UDM Pro required a canary domain, a four-state decision matrix, a dedup state machine, and a two-layer architecture to work around n8n’s Code-node sandbox. The evaluation order of the matrix is the whole trick.