Private betaRequest early access →

Sign in

Alert channels

The Command Center raises a detection when your organization's activity matches a rule: a burst of failed sign-ins, an agent touching a canary, a sign-up flood. By default you read detections in the console and the API. An alert channel tells the people who must act on one, without anyone having to open the console. It is available on Pro and Enterprise.

A channel is a destination and a severity floor. There are two kinds:

  • email sends a mail to members of your organization.
  • webhook sends a signed alert.raised notice to one of your own webhook endpoints, for a pager, a chat tool or a SIEM.

Both have a floor and can be turned off and on. For an email channel:

  • Recipients are members of your organization you choose. A recipient must be an active member with a verified email address; a free-form address is not accepted, because a typo or a hostile address is a place to send your security state. A member who leaves, or whose address stops being verified, stops receiving without anyone editing the channel.
  • An address is verified when its owner uses a link that was mailed to it: accepting an invitation, setting a first password from the link an owner invitation carries, or the sign-up link. Members created by SSO or SCIM are verified by the directory that created them. A member whose address is unverified (an account made before this applied) can verify it with Resend verification email on their profile page, and can then be chosen as a recipient. The owners of the organization are emailed when a channel is created, redirected, deleted, turned off or quietened, and that notice goes only to owners whose address is verified.
  • The floor is the lowest severity the channel sends: critical (the default), warn or info.
  • A channel can be turned off and on without losing its recipients.

For a webhook channel you name one of your own enabled webhook endpoints (endpoint_id) and nothing else: the channel holds no URL and no secret of its own, so the endpoint's HTTPS-only destination rules, its signing secret and its rotation all apply as they do for every other webhook. An endpoint that does not exist, belongs to someone else or is switched off is refused with one message, so it cannot be used to find out which ids exist.

What is sent

One email per detection, per recipient, carrying the rule's title, its severity, how many events in what window, when it was first and last seen, and a link to the Command Center (sign-in required). Nothing else: not the group the detection is about (an address, a network), not the rule's description, not any event data. The link carries the reader to those behind a sign-in.

The same rule and group raised again inside a short window is one notice, not two, for either kind. Each plan has a daily limit on alert emails per organization (Pro 100, Enterprise 1000); past it, nothing more is sent that day, the channel shows capped, and a detection of your own records that your alerts are not arriving.

What a webhook receives

A signed POST of one alert.raised event, delivered the way every webhook is (signed, retried with backoff, dead-lettered, visible in the delivery log), except that an alert is tried eight times over about an hour and not fifteen over a day and a half, because an alert that arrives a day late is not one you can act on:

JSON
{
  "id": "6f1c0d0e5c7e4c0e9a51d7b1c2a3f4e5",
  "type": "alert.raised",
  "schema_version": 1,
  "data": {
    "detection_id": "8d2f6c1e-3b7a-4a55-9f0e-1c2d3e4f5a6b",
    "rule_id": "signup-flood",
    "title": "Signup flood",
    "severity": "critical",
    "count": 12,
    "window_seconds": 600,
    "first_seen": "2026-10-26T09:12:03+00:00",
    "last_seen": "2026-10-26T09:21:44+00:00",
    "console_url": "https://console.example.com/command"
  }
}

id is fresh for every notice and is your idempotency key (delivery is at-least-once). Nothing else is ever in it: not the group the detection is about, not the rule's description, not event data, not an actor or an address. Follow console_url (sign-in required) for those. alert.raised is not in the webhook event catalogue and cannot be subscribed to through an endpoint's event_types: an alert channel is the only way it is sent.

The channel shows what happened to the delivery, not just that it was queued: queued until the delivery has finished (it is retried with backoff for about an hour first), then, within about half a minute, delivered, or failed with the classified reason (http_status, timeout, blocked, endpoint_disabled, or no_destination if the endpoint was deleted). When a channel starts failing, every owner is mailed (once: the next successful delivery re-arms it), because a channel that cannot deliver is you believing you are told and not being; an endpoint that keeps failing is switched off by the webhook plane as it is for any webhook (every failed attempt counts toward the twenty, so an endpoint that receives both your alerts and your customer events reaches it sooner), and repeated failures raise a detection of their own.

Only your organization's detections are sent. Platform-wide detections belong to the platform's operator and reach no organization's channel.

Managing channels

Reading channels needs alert_channels:read; creating, changing, testing and deleting them needs alert_channels:manage, which is human-only: an agent or API key can never change who is told about your security state, whatever else it may do. Administrators hold both.

  • Test it. POST /api/v1/alert-channels/{id}/test sends a clearly marked test, so you learn the channel works before you need it. An email test goes to the channel's recipients (each mail counts against your daily alert limit); a webhook test is a real signed alert.raised sent to the endpoint right now, and the response says whether it was delivered and why not. Ten an hour per organization. A test is never written to your delivery log.
  • Owners are told. Creating a channel, redirecting it (a different recipient set, or another endpoint), deleting it, disabling it and quietening it (raising its floor) each mail every owner of the organization, by a path the administrator who made the change does not control. Renaming a channel, re-enabling it, or lowering its floor does not.
  • Every attempt is recorded. Each delivery, successful or not, is a record in your audit log, and the channel shows its last result. Repeated failures raise a detection of their own, and so does a burst of channel changes.

In the console

Settings → Alert channels lists your channels with what became of each one's last delivery, in words ("Delivered", "Queued — waiting for the delivery to finish", "Could not deliver" with the reason, "Not sent — today's alert limit was reached"). A channel that cannot deliver is marked Needs attention, says why, and is listed first: every recipient gone, a webhook endpoint switched off or deleted, today's limit reached, or a failing delivery. A channel you turned off is not flagged; that is your choice.

From the page you add a channel, change its lowest severity, send a test, turn it on and off, and delete it. To change who is told, or which endpoint a channel sends to, delete the channel and add it again (the API's PATCH can change them in place). The page asks first before it turns a channel off, raises its lowest severity or deletes it, because each of those emails every owner of the organization; turning a channel on and lowering its severity do not.

You need alert_channels:read to see the page and alert_channels:manage to change anything (administrators hold both); without manage the controls are disabled. To choose recipients you also need members:read, and to choose a webhook endpoint you need tenant:manage. The menu entry appears on plans that include alert channels. On a plan that does not, a channel sends nothing (the page says so on each one), and you can still list, change and remove channels but not add one.

The API

See Alert channels for the endpoints. A minimal create:

Shell
curl -X POST "$BASE/api/v1/alert-channels" \
  -H "Authorization: Bearer $ACCESS_TOKEN" -H "Content-Type: application/json" \
  -d '{"name": "Security team", "min_severity": "warn", "recipient_user_ids": ["<member user id>"]}'

You can list your members' ids with GET /api/v1/members. For a webhook channel, use the id of an endpoint from webhooks:

Shell
curl -X POST "$BASE/api/v1/alert-channels" \
  -H "Authorization: Bearer $ACCESS_TOKEN" -H "Content-Type: application/json" \
  -d '{"kind": "webhook", "name": "Pager", "endpoint_id": "<webhook endpoint id>"}'