Planned work shouldn't page anyone. When you're patching a server, failing over a database, or running a migration, the alerts that follow aren't news — you already know. Pause all alerting is a tenant-wide, time-boxed mute: nothing goes out until it ends, and it ends by itself.
Why this matters: the alternative people reach for is disabling flows one at a time and turning them back on afterwards. That loses track of which flows were already off on purpose, and it relies on someone remembering to reverse it. A pause does neither.
Starting a pause
Go to Alert Flows. The bar at the top of the page shows whether alerting is live:
● Alerting is live — all active flows are delivering [⏸ Pause all alerting]
Click Pause all alerting, set a duration in hours and minutes, and optionally add a reason ("patching the SQL box"). Before you confirm, the dialog shows the wall-clock time alerting will resume:
Alerting resumes 04:30 (4h 30m from now)
Check that line. It's the quickest way to catch a duration typed an order of magnitude wrong.
Only admins can start, extend, or end a pause.
While a pause is in force
The bar turns amber and reports what the pause is doing:
⏸ Alerting paused — resumes 04:30 · 12 alerts suppressed · "patching the SQL box" · Kevin C.
Two things change elsewhere on the page: active flows show ● Active · paused, and the live-monitoring pulse is hidden. Your flows have not been altered — they're still active and still watching. They just can't deliver.
- Extend adds more time, measured from now rather than from the original end time. Asking for "another hour" at 04:25 gets you until 05:25, not 05:30.
- End now resumes alerting immediately, without waiting for the expiry.
What happens to alerts raised during a pause
They are dropped, not queued. When the pause ends you will not receive a backlog — that would turn the end of a maintenance window into exactly the flood it was meant to prevent.
| Source | During the pause | After it ends |
|---|---|---|
| JAMS, webhook, email monitor, API monitor, manual | Dropped. Nothing is queued. | The next new alert pages normally. |
| Azure Monitor, ServiceNow, Zendesk | Dropped, but the incident row is kept — find it on Incidents, where Acknowledge and Close still work. | Nothing replays. If the condition is still broken, the source system's next alert pages normally. |
The suppressed count on the bar is there so a pause can never be confused with a quiet night. If it reads 40, forty things happened that you weren't told about — the incident rows and your source systems are where to go looking.
What a pause does not do
- It doesn't change your flows. No flow is disabled, so ending the pause can't accidentally re-enable something you'd switched off deliberately — or something runaway control paused on its own.
- It doesn't stop alerts already in flight. A notification that had already gone out before the pause began keeps climbing its escalation ladder, and someone can still acknowledge it. The pause governs new alerts.
- It doesn't expire silently into the wrong state. A pause always has an end time. There's no open-ended option, on purpose: an indefinite mute is how alerting stays off for a week by accident.
Recurring maintenance
Today a pause is a one-off you start by hand. Recurring windows — "every night from 02:00 to 06:00" — aren't available yet. If you run regular batch maintenance, the closest fit for now is per-flow cooldown and the runaway control settings, or pausing at the start of each window.