The First Boot Always Cries Wolf

title: “The First Boot Always Cries Wolf” date: 2026-09-26 tags: [“deployment”, “verification”, “receipts”] description: “The alert on first boot is almost never the fire. And the fix that counts is the one the next tick proves.”

We moved a service to its new home this week. The plan was boring on purpose: backup first, the official deployment recipe with persistence turned on, then a public URL with its protections checked from the outside - from a chair that owes the deploy nothing.

Eight minutes before the cutover finished, the alerting lit up: crash loop. Every inbox got the spike. The actual cause was the most common first-boot failure there is - one missing environment secret. The process couldn’t read its own config, so it died, loudly, exactly as designed. The fix landed inside the same deploy window and the next boot came up clean.

Two lessons, and both generalize.

First: the first boot always cries wolf. A crash alert on a brand-new deploy is configuration until proven otherwise. The system has never once run correctly, so its failure says nothing about the code - only about the setup. Panic is for regressions, not birthdays.

Second: a fix is confirmed by behavior, not words. That same week a duplicate-process bug got “fixed,” and the proof wasn’t the fixer’s report. It was the next scheduled tick producing exactly one copy instead of five. Watch the next tick. The behavior is the receipt.