Skip to main content
When a check fails, Alertee sends the alert to an alert group. An alert group is a named set of recipients — webhooks, Slack channels, and email lists. Each check routes to exactly one group; checks with none set use the organization’s default group.

​
The three pieces

  • Alert group — the routing target. A check’s alert_group_id points at one. Create them per team, per severity, per project — however you want to fan out.
  • Recipient (channel) — a delivery destination attached to a group: a webhook ({ url }), a Slack channel, or an email group.
  • Email group — a reusable list of email recipients (external addresses or organization members). Attach the same list to multiple alert groups.

​
The default group

Every organization starts with a Default Alert Group and an All Organization Members email group (which auto-includes everyone in the org). Checks that don’t specify a group fall back to the default, so alerts reach your team out of the box.

​
When notifications are sent

For each incident, Alertee sends notifications at three points in its lifecycle:
  1. First alert — when the check first fails (after any grace period you’ve configured).
  2. Reminders — while the check keeps failing, a reminder goes out on an interval (default every 60 minutes, capped at 24 per incident). Reminders are labelled with how long the check has been failing.
  3. Recovery — when the check passes again, a single Resolved notification closes the loop on the same channels, and the incident is auto-resolved in the inbox.
You won’t get one email per failed run by default — a check on a 1-minute interval that’s down for an hour sends the first alert plus hourly reminders, not 60 emails. The cadence is controlled by your organization’s notification mode: The reminder interval and per-incident cap are configurable alongside the mode in your organization’s issue settings.

​
Set it up from the CLI

See the CLI commands for the full alert-groups and email-groups reference, or drive the same actions from an AI assistant with the MCP tools (create_alert_group, add_alert_recipient, create_email_group, …).
Slack recipients are set up in the web UI — they need a connected Slack workspace (OAuth). Webhooks and email groups work entirely from the CLI/MCP.

​
The webhook payload

A webhook recipient receives a JSON POST when a check fails. Use it to wire alerts into anything — a chat bot, an incident tool, or an AI coding agent (POST the payload straight to Devin’s /v1/sessions, a GitHub Action, or a Zapier hook to open an investigation automatically). Every payload carries this metadata:
Recovery notifications POST the same shape with "status": "success" and "alert_level": "resolved" — match on those to auto-close incidents in your tooling. Some fields are best-effort and only appear when available: advisory_summary once the AI diagnosis lands, and current_value / threshold_value when the triggering path computed them. Two more are gated per check (below): sql_query and result_rows.

​
What each check reveals (payload config)

The sql_query and result_rows fields are gated per check, because they can leak schema or actual data:
  • sql_query — the check’s query. Included by default (an agent needs the source to act on).
  • result_rows — the raw failing rows, capped at max_rows (default 20). Off by default — rows may contain sensitive or PII data, so this is opt-in.
Core metadata (name, status, level, message) is always sent. The conservative default — query on, rows off — applies to every check unless you change it. include_query only affects SQL checks (http, heartbeat, and push checks have no SQL query to send). Set it per check in the Alerts step of the check form, or from the CLI / MCP:
From the MCP tools, create_check / update_check take include_query, include_result_rows, and max_rows; get_check echoes the effective webhook_payload_config.