Good monitoring programs evolve.
Early on, teams usually monitor aggressively while they stabilize DNS and sending patterns. Later, they tune intervals, rename monitors for ownership clarity, and occasionally pause schedules during planned maintenance.
supports that evolution cleanly.
What you can safely change
- display name for better ownership/context
- check interval for load vs sensitivity tradeoffs
- scheduled execution state (
)
And importantly, you do this without deleting and recreating monitors.
Choosing the right interval (a pragmatic guideline)
Intervals are not about "more is better". They're about matching the cost of checks to the risk of drift.
A starting point that works well for most teams:
- primary sending domains: 5 to 15 minutes
- low-volume or secondary domains: 30 to 60 minutes
- domains in active migration: temporarily lower intervals during the change window
If you're running many monitors, batch scheduling () lets you keep intervals short without causing load spikes.
Why this matters operationally
You preserve continuity:
- same monitor identity
- same historical context
- cleaner audit trail in your tooling
That continuity makes trend interpretation and incident review much more reliable.
Endpoint
Request example
cURL example
Tune without losing history
Monitoring is not "set and forget." It's "set, observe, refine."
This endpoint gives your team controlled flexibility as your domain monitoring strategy matures.