Investigate alerts with an AI agent

Alertee alerts can do more than land in an inbox. Add a webhook to an alert group and every alert POSTs a small JSON payload to a URL you control. Point that URL at an AI agent and it can investigate the alert itself — pulling the check’s SQL, its recent run history, and the failing data over the MCP server. The webhook is the trigger; MCP is how the agent gets the detail. The payload stays small on purpose — the agent fetches live state at investigation time rather than relying on a snapshot frozen when the alert fired.

1. Add a webhook to an alert group

In the dashboard, open the alert group and add a Webhook channel with the URL the agent listens on. Webhooks sit alongside email and Slack — an alert fans out to every channel in the group. The request is a POST with Content-Type: application/json and a User-Agent of Alertee-Webhook/1.0. Custom headers (for example an Authorization bearer token so your endpoint can trust the call) are supported on the channel config.

2. The webhook payload

Every alert delivers this JSON body:

{
  "alert_id": "f1c2…",
  "timestamp": "2026-06-02T14:31:00Z",
  "check_id": "9a8b…",
  "check_name": "Failed payments (last hour)",
  "status": "failure",
  "alert_level": "critical",
  "message": "Failed payments exceeded 10 in the last hour",
  "description": "Watches the payments table for spikes in declines",
  "org_id": "3d4e…",
  "data_timestamp": "2026-06-02T14:30:00Z",
  "issue_id": "7b6c…"
}

Field	Description
`alert_id`	Unique id for this alert event
`timestamp`	When the alert was sent (RFC 3339, UTC)
`check_id`	The check that fired — the handle the agent uses with MCP
`check_name`	Human-readable check name
`status`	`failure`, `success`, or `error`
`alert_level`	`info`, `warning`, or `critical`
`message`	The alert message
`description`	The check’s description, if set
`org_id`	Organization the check belongs to
`data_timestamp`	When the underlying data was sampled (RFC 3339, UTC)
`issue_id`	Present only when the alert is linked to an incident

The payload intentionally carries metadata, not the SQL or the data. The agent fetches those in the next step using check_id.

3. Let the agent investigate over MCP

Connect your agent to the Alertee MCP server, then have it call two tools with the check_id from the webhook.

`get_check` — the definition

Returns the check’s full configuration, including the SQL it runs:

{
  "ID": "9a8b…",
  "Name": "Failed payments (last hour)",
  "Query": "SELECT count(*) AS value FROM payments WHERE status = 'failed' AND created_at > now() - interval '1 hour'",
  "Condition": { "type": "greater_than", "value": "10" },
  "AlertLevel": { "AlertLevel": "critical", "Valid": true },
  "Interval": { "CheckInterval": "five_minutes", "Valid": true },
  "Description": { "String": "Watches the payments table for spikes in declines", "Valid": true }
}

Query is the exact SQL — the agent can read it, reason about it, or run it against the source database itself.

`get_check_history` — what’s been happening

Returns recent runs (default the last 24 hours; pass hours to widen the window):

[
  {
    "ID": "…",
    "CheckID": "9a8b…",
    "Status": "failure",
    "CheckedAt": "2026-06-02T14:30:00Z",
    "DataTimestamp": { "Time": "2026-06-02T14:30:00Z", "Valid": true },
    "Details": { "value": 23, "threshold": 10 },
    "Results": [{ "value": 23 }]
  },
  {
    "ID": "…",
    "CheckID": "9a8b…",
    "Status": "success",
    "CheckedAt": "2026-06-02T14:25:00Z",
    "Details": { "value": 4, "threshold": 10 }
  }
]

Each entry carries the run Status and timestamps. Details holds the condition evaluation (the value seen versus the threshold), and Results holds the query rows captured for that run when available — so the agent can see not just that it failed but when it started and by how much.

A sample agent prompt

An Alertee alert just fired. Here is the webhook payload: {…}. Use get_check to read the SQL and get_check_history to see the last several runs, passing the payload’s org_id as organization_id so you read the right organization. Tell me when the failure started, whether it’s a spike or a steady climb, and your best guess at the cause.

With get_check + get_check_history the agent has the SQL, the recent statuses, and the failing values — enough to triage before a human even opens the dashboard.

If you belong to more than one organization

Every MCP tool takes an optional organization_id. Omit it and the tool uses your default org; pass it and the tool acts in that org — so a single agent works across all your organizations without re-linking or restarting. The alert webhook already carries the org: pass its org_id straight through as organization_id:

get_check(check_id: "9a8b…", organization_id: "<org_id from the webhook>")

If you don’t have the org id, call list_organizations to see the ones you belong to and their ids. You can only ever act in organizations you’re a member of — the backend re-checks your membership and role on every call, whatever organization_id you pass.

The CLI also supports a per-command alertee --org <id> … override, and alertee link still sets a persistent default. MCP can’t persist a link (each call is stateless), so it names the org per call via organization_id instead.

Next step

Connect a client → · Tools reference →

​1. Add a webhook to an alert group

​2. The webhook payload

​3. Let the agent investigate over MCP

​get_check — the definition

​get_check_history — what’s been happening

​A sample agent prompt

​If you belong to more than one organization

​Next step

1. Add a webhook to an alert group

2. The webhook payload

3. Let the agent investigate over MCP

`get_check` — the definition

`get_check_history` — what’s been happening

A sample agent prompt

If you belong to more than one organization

Next step