There's a big difference between continuous monitoring and urgent verification.
Continuous monitoring keeps watch in the background. Urgent verification answers one question now:
"Did this DNS change actually fix the issue?"
That's exactly what is for.
A quick reality check about DNS changes
DNS fixes are not always instantly visible. TTLs, resolver caches, and provider propagation mean you can see "fixed" from one network and "broken" from another for a while.
Run-now checks are still valuable, but treat them as a verification signal, not a magic switch. If you're debugging a high-impact incident, consider:
- checking from more than one resolver if possible
- re-running after the relevant TTL window
- watching the next scheduled runs to confirm stability
Best moments to use run-now
- right after SPF/DMARC/MX changes
- during deliverability incidents
- before high-stakes send events
- during post-incident validation
Endpoint
cURL example
What you get back
You receive immediate run results with status, score, and findings, including core signals like:
- SPF present/missing
- DMARC present/enforced
- MX record availability
A pragmatic runbook for urgent verification
When you're under pressure, use a consistent loop:
- Read monitor details first (interval, scheduling state, last run).
- Trigger run-now.
- Fix the highest-impact finding (usually auth posture or MX availability).
- Trigger a second run-now to confirm.
- Watch run history for the next few runs to ensure the fix holds.
This makes your verification repeatable and prevents "we fixed it" whiplash after a single good run.
Important concurrency behavior
If a run is already active for the same monitor, API returns . This protects your system from duplicate run storms and keeps monitoring stable.
Verify, then verify again
When the pressure is high, teams need fast, trustworthy answers. Run-now is the shortest path from uncertainty to validated domain posture.