Monitoring Run History

When domain health changes, context matters more than a single result. One run might look healthy, but a 48-hour trend can reveal repeated degradations after each deployment.

getDomainMonitorRuns gives you that context.

MailSlurp domain monitor run history with per-run findings for SPF, DMARC, and MX

Why historical runs are so valuable

Run history helps answer critical incident questions:

  • When did this problem begin?
  • Is it intermittent or persistent?
  • Did our last DNS change actually help?
  • Are failures clustered around specific times?

That's the difference between guessing and diagnosing.

A practical way to use run history during an incident

When you get a deliverability alert, it's tempting to jump straight to "fix DNS". Run history helps you slow down for 30 seconds and avoid false moves.

Use this sequence:

  1. Pull the last 20 runs.
  2. Find the first failed run and its timestamp.
  3. Compare that time to known changes: DNS edits, sending provider changes, deploy windows.
  4. Trigger a run-now check after your remediation.
  5. Confirm that both the latest run is healthy and the next few scheduled runs stay healthy.

This prevents the classic mistake: one healthy rerun causes premature celebration, then the next scheduled check fails again.

Endpoint

GET /domain-monitor/monitors/{monitorId}/runs

Query parameters

  • since
  • before
  • status
  • limit

cURL example

curl -sS "https://api.mailslurp.com/domain-monitor/monitors/$MONITOR_ID/runs?status=FAILED&limit=20" \
  -H "x-api-key: $API_KEY"

Tips for making the response useful in tooling

If you're building internal dashboards or runbooks, a few small choices make run history dramatically more actionable:

  • show the "top finding" inline per run so operators can scan quickly
  • link each run to the monitor detail view (configuration + current state)
  • keep a quick filter for the last 24 hours (most incidents are recent)
  • group intermittent failures by finding type (SPF, DMARC, MX) rather than by timestamp alone

The goal isn't just storing history. It's turning history into a timeline someone can understand in a minute.

Practical UI recommendations

  1. Default to latest-first ordering.
  2. Add one-click filters for CRITICAL and FAILED.
  3. Show findings inline (or in expandable rows) so operators don't have to open each run.

Build a timeline

Strong monitoring isn't just detecting issues. It's preserving the timeline that explains why they happened.