How an alarm actually reaches somebody.

[
  {
    "host_id": "web-01",
    "text": "quote signature failed to verify",
    "severity": "critical",
    "kind": "signature-invalid",
    "formatted": "[signature-invalid] web-01: quote signature failed to verify"
  },
  {
    "host_id": "web-02",
    "text": "3 pending item(s) aged past the 24h review SLA",
    "severity": "warning",
    "kind": "sla-exceeded",
    "formatted": "[sla-exceeded] web-02: 3 pending item(s) aged past the 24h review SLA"
  }
]

Five fields, added to in this order as the feature grew — a plugin only reads what it needs, and one written against just the first three keeps working unchanged forever, since every addition here has been purely additive to the array.

Every kind value

One per distinct failure mode the verifier actually produces — nothing here is speculative, each maps directly to a real code path.

Per-channel formatting

Set ETMINAN_NOTIFY_<CHANNEL>_FORMAT (channel name uppercased) in verifier.env to change one channel's formatted field — a {kind}/{host_id}/{text}/{severity} template. Purely a config change: no plugin script edit, no re-hashing, no re-allowlisting. Unset falls back to "[{kind}] {host_id}: {text}". Two channels can use two different templates for the exact same finding — and the same knob exists for email too, as ETMINAN_NOTIFY_EMAIL_FORMAT.

Renders four representative fake findings (one signature-invalid, one pcr-mismatch, one sla-exceeded, one plugin-failure) through whatever _TEMPLATE/_FORMAT/_SEVERITIES is currently configured, and prints the result: the full email (subject + body) and, per channel in ETMINAN_NOTIFY_CHANNELS (or just --channel <name>), the raw JSON payload that would hit its plugin's stdin.

Never executes a plugin, never calls sendmail — nothing is sent for real, so it's safe to run any time, including against a channel that isn't allowlisted yet (preview never touches the verify-then-exec path at all). This previews the verifier's side of the contract only: what a Slack/PagerDuty/webhook _TEMPLATE does with that payload happens inside the plugin script, which preview deliberately never runs. Pipe the printed payload into the script by hand if you want to see its actual transformed output — that performs the real send, so only do that deliberately.

plugins verify already confirms a channel is allowlisted, root-owned, and its pinned hash matches — an integrity/config check, not a functional one. It never executes the plugin, so a channel can pass plugins verify cleanly and still fail the first time it's needed for real: a wrong PagerDuty routing key, an expired Slack webhook URL, an outbound firewall rule blocking the verifier host.

notify-test closes that gap. It builds one synthetic finding (kind: "test", severity: "warning", host_id "notify-test" — distinct from any real monitored host so it can never collide with a real host's own PagerDuty dedup_key) and pipes it through the plugin's real invocation path — the exact same verify-then-exec call a live run cycle uses. Unlike notify-preview, this performs a real send and reports the plugin's actual exit status (and any stderr it printed) back to you. It also deliberately ignores that channel's configured _SEVERITIES filter — you're asking to test this channel right now, not to have the attempt silently skipped because a test finding's severity doesn't happen to match what you've configured for real alerts.