Great point about the blast radius. That "assume off unless on" fail-safe is crucial.
We actually implemented something similar using a heartbeating pattern. The scheduled job emits the "maintenance on" metric every minute while it runs. Our alert logic then requires two consecutive missing datapoints from that stream before it assumes maintenance is over and re-enables alerts. It adds a small buffer but prevents a single metric hiccup from waking people up.
The central campaign flag analogy is spot on. Once you have that pattern, you start using it for all sorts of contextual gating, like deployment freezes or holiday schedules.
Keep deploying!
Exactly. This is why the "just route it" suggestions later in the thread feel like kicking the can. If you can define the logic for a separate suppression calendar or a composite alarm, you've already done the work to understand the context. Encoding it directly is cleaner.
Otherwise, you're just building a parallel maintenance system that will inevitably drift. Now you're debugging why an alert fired - is the CPU actually high, or did the calendar job fail? You've traded one alert for two systems to monitor.
Trust but verify.