Skip to main content
A check watches something on a schedule and opens an incident (and fires an alert) when it goes wrong. Most checks run a SQL query against your database and evaluate the result against a condition, but Alertee also has website/API checks, heartbeat (dead-man’s-switch) checks, and push checks (your own job sends us the number — see push checks) — see Check types. The rest of this page covers SQL checks.

​
Who owns the check

Every check is owned by either you or Alertee’s agent:
  • You — you wrote the SQL and condition. Alertee runs it exactly as written and never changes it.
  • Alertee — the agent authored the query and threshold from your schema and keeps it tuned on a review cadence. These are marked managed by Alertee. See Managed checks.
You can take a managed check back at any time; it becomes user-owned and the agent stops touching it.

​
Anatomy of a check

​
Writing a good query

Alertee supports two shapes of query, and the shape you choose determines which conditions are available:
  • Single-value check — return one row with one numeric column. The condition compares that number against a threshold.
  • Grid check — return multiple rows with name and value columns, one row per dimension (store, region, ticker, endpoint…). The condition is evaluated across every row. See Conditions for the full set.
A query that returns multiple rows is only a problem for a single-value check. If you want to monitor many dimensions at once, alias your columns to name and value and pick a grid condition.
Use @now - INTERVAL '...' to scope your query to a sliding window that matches your check interval. A 5-minute check should look at the last 5–10 minutes of data.

​
Query variables

You can reference these variables in your SQL. They’re bound at run time: NOW() and current_timestamp still work and are rewound during simulations too.

​
Simulate (backtest)

From a check’s menu (or while creating one), choose Simulate… to replay the query over a past window — it rewinds @now to each point in time and shows when an alert would have fired, without sending anything. It’s off by default because it runs one query per step against your database; you can stop it at any time. For a saved check you can optionally save the run into history, then delete it later from the check’s details.

​
Check status

A check can also be disabled (it stops running), muted (keeps running but sends no alerts — handy while tuning), snoozed, or limited to an active schedule — a calendar (closed days) and/or custom hours — so it only runs when it matters. To avoid paging on a brief blip, give a spiky check a grace period so it tolerates a few failures before alerting.

​
Connections

Connections store an encrypted link to your database. Alertee supports PostgreSQL and ClickHouse, self-hosted or managed (Supabase, Neon, AWS RDS, Google Cloud SQL, ClickHouse Cloud, …), as long as the database is reachable from the public internet. Credentials are encrypted at rest using per-organization keys. Alertee uses read-only connections — it will never modify your data. Revoke access any time by rotating the database user.

​
Alert groups

An alert group is a named collection of notification channels. You can have multiple groups (e.g. “On-call”, “Data team”) and assign different checks to different groups. Channels supported:
  • Email — send to individual addresses or managed email groups
  • Slack — post to a channel via OAuth
  • Webhook — POST a JSON payload to any URL