Home / Docs
How DiffMon works across monitoring, alerts, security, and API integration.

Incident inbox and message log

How incidents are created, how to triage them, and where to audit every delivery attempt.

DiffMon separates change triage from delivery diagnostics:

  • Incidents (/app/incidents) answers: What needs attention right now?
  • Message log (/app/message-log) answers: What was sent and did it succeed?

This separation keeps noisy transport details out of your triage queue.

How incidents are created

An incident is created when a monitor run produces a changed diff and no matching open/acknowledged incident exists for the same monitor + fingerprint.

At a high level:

  1. Worker creates a diff for each snapshot run.
  2. If diff is changed, worker attaches it to an incident.
  3. If no matching unresolved incident exists, a new incident opens.
  4. If a matching incident exists, lastActivityAt and lastDiffId are updated.

Notes:

  • baseline_reset diffs are not incident-generating.
  • Diff history remains immutable even when incidents are grouped.

Incident statuses and operator behavior

open

  • Meaning: active change requires attention.
  • Recommended action: review latest diff + delivery trail.

acknowledged

  • Meaning: someone has seen it, but it is not closed.
  • Recommended action: use when ownership is clear but remediation is pending.

resolved

  • Meaning: incident is closed for triage.
  • Recommended action: use after you decide the change is accepted/fixed.

If the same change pattern appears again after resolution, a new incident can open.

Policy rules can suppress notification delivery for matched changes, but incidents and diff evidence still persist. See Policy rules for routing/suppression behavior.

Where to find details

Incidents page (/app/incidents)

Use this page for triage and ownership:

  • monitor context (name + URL)
  • opened time, last activity, age
  • first/last diff references
  • notification rollup (sent/failed/destination count)
  • actions: Acknowledge, Resolve

Message log page (/app/message-log)

Use this page for transport diagnostics and audit:

  • destination + template used
  • delivery status and attempts
  • latency / HTTP status
  • diffId / incidentId / requestId correlation
  • latest response snippet or sanitized error
  1. Start in Incidents.
  2. Open incident row and check scope/age/last activity.
  3. Jump to Message log filtered by incidentId if delivery verification is needed.
  4. Return to incident and Acknowledge or Resolve.

Filters that matter most

Incidents

  • status (default unresolved)
  • monitor
  • direct incidentId

Message log

  • time range
  • status
  • destination type
  • monitor
  • incidentId
  • requestId

These filters are enough to answer "what changed?", "who was notified?", and "why did delivery fail?" quickly.