Notifications & webhooks

Beyond the in-app inbox and toasts, HeliosLogs can POST a webhook whenever an alert is raised — to Slack, a chatops channel, or any HTTP endpoint.

Configure the global target under Admin → Integrations.

Webhook settings

Setting	Notes
Enabled	Master on/off for webhook delivery.
URL	The endpoint alerts are POSTed to.
Format	generic (default) or slack.

Use Send test to fire a synthetic alert at the URL and confirm it's wired up.

Payload formats

Generic — the full alert as JSON, for your own integrations:

{
  "event": "alert.created",
  "alert": {
    "id": "alt_…",
    "monitor_id": "mon_…",
    "monitor_name": "Checkout errors",
    "env": "prod",
    "severity": "high",
    "title": "296 errors in 5m is above the threshold of 50",
    "summary": "…",
    "evidence": { "...": "..." },
    "acknowledged": false,
    "created_at": 1750000000000
  }
}

Slack — a ready-to-post message, compatible with Slack incoming webhooks (and Mattermost / Discord Slack-compatible endpoints):

{ "text": "*[HIGH]* Checkout errors: 296 errors in 5m is above the threshold of 50\n<summary>" }

Per-monitor overrides

A monitor can specify its own webhook URL and format, which replaces the global target for that monitor's alerts. Use this to route, say, high-severity production monitors to a paging channel while everything else goes to a general channel.

Delivery semantics

Delivery is best-effort and fire-and-forget: HeliosLogs POSTs the payload with one automatic retry on failure. A failed delivery is logged (and searchable in the _helioslogs self-log) but never blocks or fails the alert itself — the alert is always recorded in the inbox regardless.

SSRF protection

Outbound webhook URLs are validated before each request; private, loopback, and link-local targets are blocked. If you need to deliver to an internal endpoint, front it with an allowed address. See Security hardening.