Tools reference

​

list_checks

List all checks in the linked organization. Parameters: none Example prompt:

“Show me all my Alertee checks.” / “Which of my checks are currently silenced?”

Returns: Array of check objects (id, name, status, interval, connection, query, …). Each is annotated with quiet_now (alerts currently suppressed) and quiet_reason (e.g. a snooze, a calendar holiday, or off-hours), so you can see what’s silenced without a get_check per check.

---

​

get_check

Get a single check’s full detail. Parameters: Returns: The check object, plus a schedule field — the resolved view of the check’s calendar, durable quiet window, active snooze, and whether it is quiet_now (with a summary and quiet_reason). Calendar/quiet/snooze are stored separately, so this is how you confirm what scheduling is actually in force. quiet_now is computed by the same logic the monitor uses to suppress, so it never disagrees with real behaviour. The snooze_check, set_check_schedule, and update_check (calendar) tools echo the same schedule back, so you can verify a write without a second call. It also returns the effective webhook_payload_config (include_query, include_result_rows, max_rows) — what webhook alerts will include for this check. For a push check it additionally returns ingest_url — where the user’s job POSTs its number — so you can hand it back after the create call.

---

​

get_check_history

Get a check’s recent run history (status over time). Parameters: Example prompt:

“How has my ‘orders’ check been doing over the last day?”

Returns: By default, { summary, snooze_events } — summary is a digest (totalRuns, statusCounts, status transitions, durationMs stats, and the last 10 recent runs) so it stays small. With summary=false, returns { results, truncated, total, snooze_events } where results is the raw run rows (Status, CheckedAt, details). snooze_events lists when the check was manually snoozed, until when, and why.

---

​

get_check_changelog

Get a check’s change history — what changed about its configuration, when, and by whom. This is distinct from get_check_history, which is run/status history. Parameters: Example prompt:

“What changed on my ‘optionchain equities’ check recently?”

Returns: { entries } — a newest-first timeline. Each entry has at, actor, summary, and kind, one of:

• config — a human/agent edit through update_check (query, condition, interval, cron schedule, alert routing, grace period). Carries fields with before/after for each changed field.
• ai_review — an Alertee-authored rewrite of a managed check. Carries the reasoning and the query/condition diff.
• schedule — a calendar, quiet-window, or snooze change (e.g. “Set calendar: NYSE calendar”).

---

​

run_check

Run a check immediately and return the result — useful for testing a check without waiting for its schedule. Parameters: Returns: { verdict, success, result } (or { success: false, error } if it couldn’t run). verdict is a plain-English summary that states whether the check is healthy or alerting and what “healthy” means here (e.g. HEALTHY — Value 12.00 is greater than 0.00 (healthy when value > 0)), so the comparison’s polarity is never a guess — the condition describes the healthy state and the check alerts on violation.

---

​

get_plan

Show the organization’s plan and usage — so you can check there’s headroom before creating checks or connections. Parameters: none (accepts organization_id) Example prompt:

“What plan am I on, and do I have room for more checks?”

Returns: { plan, subscription_status, checks: { used, limit }, data_sources: { used, limit }, min_interval_minutes }. Free organizations report the free plan and its limits.

---

​

create_check

Create a new check. Pick check_type: sql (default — a database query, single-value or grid), http (a website/API endpoint), api_metric (track a number from a JSON API — see API metric checks), heartbeat (a dead-man’s-switch for a cron job), or push (the user’s own cron POSTs a number to us — no credentials, works from a private network; see push checks). See Check types. Common parameters: SQL checks (check_type: sql): † For a single-value check, condition_type (plus its value field) is required. Grid any_cell/all_cells need condition_type+threshold (numeric comparisons only); dimension_missing/dimension_added need neither. Website / API checks (check_type: http): API metric checks (check_type: api_metric): fetches a JSON API, extracts a value, and evaluates it like a SQL single-value check (the condition fields above apply; they’re optional — without one the check just verifies fetch + extraction). A value_path yielding [{name,value},…] rows makes it a grid check (set evaluation_type). Heartbeat checks (check_type: heartbeat): the response includes a heartbeat_url your job should call on success. Push checks (check_type: push): the response includes an ingest_url, an ingest_token, and an example_curl — relay them to the user, since nothing is monitored until their job POSTs to that URL. There is no auth header: the token in the URL is the credential, so treat it as a secret. Push checks do take a condition: the pushed number is evaluated against condition_type + threshold (or evaluation_type for a grid push) the instant it arrives, exactly like a sql check. The condition describes the healthy state and the check alerts when it’s violated. Body shapes are {"value": 42} for a single value and {"rows": [{"name": "eu-west", "value": 12}]} for a grid. The ingest token is minted by the server and preserved across updates, so it is never set by the caller. Grid polarity — read before choosing evaluation_type: Example — single value:

“Create an Alertee check that alerts if there are no new orders in the last 5 minutes. Use the production Postgres connection.”

Claude will call list_connections, then create_check with a greater_than 0 condition (healthy while at least one order arrives) and a 5-minute interval. Example — grid:

“Monitor orders per store: alert if any store has fewer than 5 orders in the last 15 minutes.”

Claude will call create_check with a SELECT store_id AS name, COUNT(*) AS value … GROUP BY store_id query, evaluation_type: all_cells, condition_type: greater_or_equal, threshold: 5 — every store’s count must stay ≥ 5, so the check alerts the moment any store drops below it. Example — website:

“Add a check that alerts if alertee.io stops returning 200 or gets slow.”

Claude will call create_check with check_type: http, url: https://alertee.io, expected_status: 200, and max_response_time_ms. Example — API metric:

“Watch our cloud compute usage and alert if we burn past 50k minutes this month.”

Claude will call create_check with check_type: api_metric, your provider’s usage endpoint as the url, your token in headers, a value_path pointing at the month-to-date figure, and a less_than 50000 condition (healthy while under budget). Example — heartbeat:

“Set up a heartbeat for my nightly ETL — it should run once a day.”

Claude will call create_check with check_type: heartbeat and expected_interval_mins: 1440, then hand you back the heartbeat_url to curl at the end of the job. Example — push:

“I can’t give you database credentials. I’ll run the query myself — alert me if my hourly order count drops below 100.”

Claude will call create_check with check_type: push, condition_type: greater_or_equal, threshold: 100 (healthy at 100 or more, alerting at 99) and a staleness_mins window, then hand you back the ingest_url and the curl one-liner to add to your cron.

---

​

update_check

Update a check. This is a partial update — only the fields you pass change; everything else is left untouched. Parameters: The condition fields, if provided, replace the whole condition — call get_check first if you only want to tweak part of it. managed_by: alertee hands the check to Alertee, which re-authors and re-reviews it on a cadence. calendar keeps the check quiet on that calendar’s closed days — weekends and its holidays (NYSE = US market holidays, UK = UK bank holidays). It’s day-level only: time-of-day stays with the check’s custom schedule, and the two compose. Example prompts:

“Pause the ‘Replication lag’ check.” → update_check with enabled: false. “Mute alerts for the ‘orders’ check while I tune it.” → update_check with alerts_enabled: false. “Don’t alert on the latency check unless it fails 3 times in a row.” → update_check with grace_period_enabled: true, grace_period: 3, grace_period_type: consecutive. “Have Alertee manage the ‘orders’ check and follow the NYSE calendar.” → update_check with managed_by: alertee, calendar: NYSE.

---

​

delete_check

Delete a check by ID. This cannot be undone. Parameters: Returns: { success: true }.

---

​

suggest_check_schedule

Analyse a check’s run history and suggest an active schedule (when the feed normally has data). A suggestion only — pass apply: true to set it as the check’s custom schedule. Parameters:

---

​

snooze_check

Temporarily silence a check’s alerts. Defaults to the rest of the local day and auto-expires; end it early with unsnooze_check. Parameters: Example prompt:

“Snooze the ‘replication lag’ check for the rest of the day — we’re doing a migration.”

Returns: { success, schedule } — the resolved schedule, so you can confirm the snooze and its snoozed_until.

---

​

unsnooze_check

End a check’s active snooze immediately, so its alerts resume now instead of waiting for the snooze to expire. No-op if the check isn’t snoozed. Leaves recurring quiet windows and calendars untouched. Parameters: Example prompt:

“The migration’s done — un-snooze the replication lag check.”

Returns: { success, schedule }.

---

​

set_check_schedule

Set or clear a check’s custom schedule — the recurring hours/days it’s expected to be active. Outside it the check is skipped, so it won’t alert. This handles time-of-day; to also stay quiet on a calendar’s holidays (and weekends), attach a calendar via update_check — the two compose. Parameters: † Provide before and/or after, or clear: true. Example prompt:

“Only alert on the ‘option chain has rows’ check during US market hours.” → set_check_schedule with before: 09:30, after: 16:00, weekdays: true.

---

​

list_connections

List all database connections in the linked organization. Parameters: none Returns: Array of connection objects with id, name, type. Tip: Call this first when creating a check so Claude can pick the right connection.

---

​

list_organizations

List all organizations the authenticated user belongs to. Parameters: none Returns: Array of organization objects with id, name, slug. Use case: Useful if you need Claude to know which organization is currently linked, or to switch context.

---

​

create_organization

Create a new organization. You become the owner. Parameters: Returns: The new organization, including its id. On the local server this also switches your linked organization to the new one (like alertee org create). On the remote server, pass the returned id as organization_id to create_connection / create_check to provision into it. Example prompt:

“Create an Alertee organization called Acme, then add my Postgres connection and a check for it.”

---

​

create_connection

Create a database connection. The connection_string is encrypted server-side and tested before saving — a bad URI or unreachable host returns an error. Parameters: Returns: The created connection (use its id with create_check).

---

​

update_connection

Update an existing connection — rotate its credentials (pass a new connection_string) or rename it. Re-tested before saving. Only the fields you pass change. Parameters: Example prompt:

“I rotated the Postgres password — update the ‘Acme prod’ connection.”

---

​

test_connection

Test an existing database connection. Parameters: Returns: { success, permissions, warning } (or { success: false, error }).

---

​

preview_api_metric

Probe a JSON API endpoint while authoring an api_metric check — without saving anything. Returns the response and the discoverable gjson paths (e.g. data.0.value) so you can pick a value_path instead of curling first. Supports query_params (auto-encoded) and headers, so you can preview an HTTP-SQL endpoint like Tinybird. Parameters: Returns: { status_code, response_time_ms, valid_json, paths: [{ path, sample }], extracted? }.

---

​

list_alert_groups

List alert groups in the organization. A group routes a check’s alerts to its recipients. Parameters: none Returns: Array of alert group objects.

---

​

create_alert_group

Create an alert group (a container for recipients). Add recipients with add_alert_recipient; route a check to it via create_check’s alert_group_id. Parameters: Returns: The created alert group, including its ID.

---

​

update_alert_group

Rename an alert group, change its description, or make it the org default. Only the fields you pass change. Parameters:

---

​

delete_alert_group

Delete an alert group by ID. Checks using it fall back to the default group. Parameters:

---

​

send_test_alert

Send a clearly-labelled test alert through an alert group’s real channels (email, Slack, webhook) to verify delivery. It does not touch any check or its condition and creates no incident — use it to confirm “will I actually get paged?” without forcing a check to fail. Omit alert_group_id to use the org’s default group. Parameters: Returns: { success, message } — the message names how many channels it reached.

---

​

list_alert_recipients

List the recipients (channels) in an alert group. Parameters: Returns: Array of channel objects (id, channel_type, config, email_group_id, …).

---

​

add_alert_recipient

Add a recipient to an alert group. Parameters: † Provide url for webhooks, or email_group_id for email groups. Slack is configured in the web UI (it needs a connected Slack workspace). Example prompt:

“Create a ‘Acme oncall’ alert group and POST its alerts to https://hooks.example.com/abc.”

---

​

remove_alert_recipient

Remove a recipient from an alert group by its channel ID (from list_alert_recipients). Parameters:

---

​

list_email_groups

List email groups (reusable recipient lists) in the organization. Parameters: none Returns: Array of email group objects (id, name, member_count, …).

---

​

create_email_group

Create an email group (a reusable list of email recipients), optionally with initial members. Attach it to an alert group with add_alert_recipient (type email_group). Parameters: Returns: The created email group, including its id.

---

​

update_email_group

Rename an email group, change its description, or toggle auto-adding org members. Only the fields you pass change. (Manage member addresses with add_email_group_members / remove_email_group_member.) Parameters:

---

​

delete_email_group

Delete an email group by ID. Alert groups using it lose those recipients. Parameters:

---

​

add_email_group_members

Add one or more email addresses to an email group. Parameters:

---

​

remove_email_group_member

Remove an email address from an email group. Parameters:

---

​

list_inbox

List inbox items (incidents) in the organization. Parameters: Returns: Array of incident objects (id, title, status, severity, startedAt, …). check_id + status: ["resolved"] is how an agent mines a check’s past incidents: list them, then get_inbox_item each one to read the comments and see how it was fixed before. Example prompt:

“What’s open and critical in my Alertee inbox right now?”

“This check is failing again — look at its past incidents and how we resolved them.”

---

​

get_inbox_item

Get a single incident with its timeline and comments. Comments carry resolution context from past handling (what was wrong, how it was fixed) — read them before diagnosing a recurring incident. Parameters: Returns: { issue, timelineEvents, comments }.

---

​

comment_on_inbox_item

Add a comment to an incident. Use it to record diagnosis and resolution context (the root cause, the fix that was applied) so the team — and future agents — can see it when the incident recurs. By default the comment is emailed to the email channels of the check’s alert group. Parameters: Returns: The created comment plus an emailed flag confirming whether it went to the alert group. Example prompt:

“Resolve that incident and leave a comment explaining the orders table was stale because the ETL cron was paused.”

---

​

edit_inbox_comment

Edit one of your own comments — to correct or refine a recorded diagnosis instead of appending another comment. You can only edit comments you authored; editing does not re-send the email. Get the comment_id from get_inbox_item’s comments. Parameters: Returns: The updated comment.

---

​

delete_inbox_comment

Delete one of your own comments. You can only delete comments you authored. Get the comment_id from get_inbox_item’s comments. Parameters: Returns: { success: true }.

---

​

acknowledge_inbox_item

Acknowledge an incident. Parameters:

---

​

resolve_inbox_item

Resolve an incident. Parameters:

---

​

get_inbox_digest

Get the inbox digest — a briefing plus active/critical/resolved incident counts. Parameters: none Returns: { briefing, activeIncidentCount, criticalCount, updated24h, resolved24h, pendingImprovements }.

---

​

list_webhook_receivers

List inbound webhook receivers in the organization. Parameters: none Returns: Array of receiver objects (id, name, severity, enabled, …).

---

​

create_webhook_receiver

Create an inbound webhook receiver. External tools POST to the returned URL to open inbox incidents. Parameters: Returns: { receiver, webhookUrl } — POST a JSON body like {"title":"…","severity":"critical","dedup_key":"…"} to webhookUrl.

---

​

delete_webhook_receiver

Delete an inbound webhook receiver by ID. Parameters: