Skip to main content
When a check’s condition is breached, Alertee doesn’t just send a notification — it opens an incident in your Inbox. The Inbox turns alerts into owned work: something to acknowledge, assign, resolve, and learn from.

​
Incident lifecycle

An incident moves through three states: Along the way you can assign an incident to a teammate so it has a clear owner. If a failing check recovers on its own, its incident can auto-resolve — so transient blips don’t pile up as manual work.

​
Performance items

Not every inbox item is a failure. When a check’s query starts running slowly, Alertee opens a separate performance item — with index suggestions where it can find them — so you can keep the load on your database light. These auto-resolve when the query is fast again. See Query performance.

​
AI diagnosis

When an incident opens, Alertee runs the failure through an LLM (Claude Sonnet) once and attaches a short, plain-English diagnosis to the incident:
  • Execution errors (timeouts, connection failures, bad credentials, missing tables, SQL errors) get a what-broke-and-how-to-fix read — e.g. “the query hit the 30s timeout scanning orders without an index on created_at; add CREATE INDEX ON orders (created_at).” It reads your actual table schema and indexes (so it won’t suggest an index you already have) and reuses the sibling performance item’s EXPLAIN output where one exists.
  • Condition breaches get a why-this-fired read — and, for checks you manage yourself, a concrete suggestion (tune the threshold, rewrite the query, or hand the check to Alertee).
The diagnosis is advisory — a starting point to check against your data, not a verdict. It also rides along on the alert itself: Slack, email, and webhook notifications carry the summary when it’s ready (the very first alert may beat it by a second; reminders and re-fires carry it). Every diagnosis is computed fresh against the live incident — Alertee never shows you a stale, cached answer (the whole point is that your data is live). It simply doesn’t run on every fire: it runs only when an incident opens or reopens, a flapping check is re-diagnosed at most once an hour, and never on a healthy run or a re-fire of an already-open incident.

​
Resolving with an outcome

When you resolve an incident you classify what it actually was. The outcome is the signal Alertee uses to reduce noise:

​
Comments

Every incident has a comment thread. Use it to keep the why with the incident: what was actually wrong, what you changed to fix it, anything the next person (or an AI agent) should know if the same check fires again. Comments live on the incident forever, so past incidents on a check become a searchable history of diagnoses and fixes. By default a comment is emailed to the email channels of the check’s alert group — the same people who got the alert — so the team sees updates without being CC’d manually. Posting from the CLI (alertee inbox comment <id> "…") or the comment_on_inbox_item MCP tool works the same way; pass --no-notify / notify=false for a silent note. You can edit or delete your own comments — to fix a typo or refine a diagnosis rather than appending a correction. Editing shows an “edited” marker and does not re-send the email. From the CLI use alertee inbox edit-comment <id> <commentId> "…" and alertee inbox delete-comment <id> <commentId>, or the edit_inbox_comment / delete_inbox_comment MCP tools (you can only edit or delete comments you authored). Notes attached when acknowledging or resolving an incident also land in the comment thread. To revisit a specific check’s history, filter the incident list to that check (alertee inbox list --check <id> --status resolved, or the check_id parameter on the list_inbox MCP tool) and read the comments on each past incident — the diagnoses and fixes travel with the check.

​
Self-improving alerts

Alertee watches the pattern of incidents and outcomes per check. When a check is noisy — lots of incidents that resolve fast, get marked transient, or get ignored — the LLM looks at the whole picture (the SQL, the schedule, when and how often it fires, how you’ve been resolving it) and decides the single most useful fix, or that the noise is legitimate and nothing should change. When it has a suggestion it raises an improvement in your Inbox: a concrete, one-click change such as widening the grace period, setting a quiet window, or converting the check to a baseline-aware managed check, with the reasoning attached. You accept or dismiss it; nothing changes without your decision. This is the feedback loop: incidents → outcomes → fewer, better alerts over time.

​
Daily digest

Instead of (or alongside) per-incident notifications, you can receive a daily digest summarizing the day’s incidents and their state. Configure it under the Inbox settings.

​
External alerts

The Inbox isn’t only for Alertee’s own checks. An external tool can open an incident by POSTing to an inbound webhook receiver URL, so your data incidents live in one place. Create a receiver from the CLI (or the create_webhook_receiver MCP tool) — it prints the URL to POST to:
See CLI commands for receivers and inbox, or the MCP tools.