Incident triage

Triage deliverability alerts in a fixed order: classify, contain, diagnose, resolve.

Alert noise becomes manageable when every incident follows the same four steps. This guide maps GTM's alert and recovery signals onto that triage order.

Classify by scope, not by panic

The first triage question is what the alert actually covers. A failed smoke test on one inbox is a different incident from a blacklist hit on a shared IP. GTM alerts carry the entity they fire on, which makes scope the cheapest classification signal available.

  • Single-inbox alerts: start with credentials and smoke-test history.
  • Domain-level alerts: start with DNS drift and DMARC sources.
  • IP-level alerts: start with blocklist checks and shared-tenant impact.

Contain to the classified scope

Containment should match the blast radius. Pausing one inbox for a credential failure is proportionate; pausing a workspace for it is not. GTM's recovery workflow records the containment as a tracked event so the response is auditable and reversible.

  • Pause sending on the affected resource.
  • Let export gating block the affected rows automatically.
  • Escalate to approval-gated fixes when containment is not enough.

Diagnose and close on evidence

With the incident contained, diagnose using the public and internal signals: content inspection for spam triggers, DNS and blacklist state, DMARC aggregate sources, engagement trends. Close the incident when the failing check passes again and the recovery event records the resolution.

Common questions

Should every alert become an incident?

No. Informational and low-severity alerts often resolve on the next scheduled check. Triage promotes an alert to an incident when it blocks readiness, exports, or an active campaign.

What if the same incident keeps reopening?

Repeat incidents on the same resource are a replacement signal. Move from repeated containment to the domain replacement and recovery workflow, and review whether the plan under-provisioned capacity.