A quarterly resilience drill deliberately induces a monitored condition and times how long it takes until a human acknowledges it. Why is repeating this drill the right practice when the alerting was already proven working once at cutover?

The alerting chain - event to threshold to transport to collector to inbox to a responding human - is owned piecemeal, and every link changes over time: rosters rotate, SMTP credentials expire, firewalls get tightened, thresholds get re-tuned. A single induction drill measures the whole chain's end-to-end latency at the only time that matters, now, and doubles as practice for whoever is on call this quarter. The cutover test's value expired the first time any link changed, which is why the practice is periodic rather than archival. The drill targets the information chain, not hardware failover - induced conditions are deliberately chosen to be safe, such as a test event or a maintenance-mode threshold - and hardware failover is a separate class of test entirely. Support entitlements are contractual, not drill-dependent: no vendor conditions warranty coverage on internal drill paperwork, and assuming otherwise invents a vendor fact. Measuring only vendor ticket routing while presuming the internal chain healthy inverts the actual risk - the frequently changing internal links are exactly what the drill must verify. Exam caveat: schedule drills under change control and announce them, so an induced condition never triggers a real incident response. Operational check: record drill date, induced condition, first-alert time, and acknowledgement time each quarter, and trend the end-to-end latency across quarters.