Alert webhooks (any SIEM)

3AM doesn't replace your monitoring. Besides polling the alert sources you connect, it accepts the first alert from whatever you use, by webhook, and takes it in at once (within 0.2 s).

POST https://3am.bank.internal/v1/alerts/<source>
Authorization: Bearer <ingest token>

The ingest token is in ~/.3am/ingest-token (single server) or the threeam-ingest Secret (Kubernetes).

{"name": "HighErrorRate", "severity": "critical", "status": "firing", "service": "payments-api",
 "labels": {"instance": "pay-01:8080"}, "summary": "5xx above 5% for 5m", "id": "alert-123"}

Several at once: {"alerts": [ … ]}.

curl -s -X POST -H "Authorization: Bearer $(cat ~/.3am/ingest-token)" -H 'Content-Type: application/json' \
  -d '{"name":"ThreeAMWebhookTest","severity":"critical","status":"firing","service":"monitoring"}' \
  http://127.0.0.1:8700/v1/alerts/generic
# 202 {"accepted": 1, "resolved": 0, "signals": [...]}

How it's taken inCopy Anchor Link

• Severity becomes critical, warning or info (unknown values become warning); status firing or resolved.
• The fingerprint is stable: your tool's own id, else a hash of the source, name and identifying labels.
• Labels are flat, with your tool recorded in labels.siem.
• A firing alert is held until your tool sends resolved, or until it hasn't been re-sent for 4 hours; the set survives restarts (data/webhook-alerts.json).
• Then exactly the same path as a polled alert: baseline, grouping by service, correlation, the 20 s debounce.

400 for a body no normaliser can read. Every push is a signal.pushed event. Network: your tool needs to reach 3AM on 8700 (or your reverse proxy) for this; it's the only inbound path 3AM uses for alerts.