Skip to main content
Every time a check runs, Alertee measures how long its query takes to run and fetch results against your database. That timing is stored with each result, so you can see whether a check is cheap or heavy — and Alertee tells you when one gets slow.

​
What you’ll see

In the chart. Hover any point in a check’s history and the tooltip shows Ran in N.Ns. A run at or over the slow threshold is labelled slow. In your inbox. When a query takes longer than the threshold to run, Alertee opens a performance item for that check (separate from any failure incident — the two never interfere). Its severity scales with how slow the query is: The item auto-resolves once the query is fast again. A query so slow it times out (hits the run cap and is cancelled with context deadline exceeded) is the extreme of this — it raises a critical performance item with index suggestions alongside the failure incident, so the worst-performing query still shows up here rather than only as a bare error. In alerts. If a check is also firing an alert (e.g. it failed), and the run was slow, the alert carries a ⚠️ This check's query took N s to run line so recipients know to look at the performance item too.

​
Index suggestions

When a run is slow, Alertee runs a plain EXPLAIN on the query (it never runs EXPLAIN ANALYZE, so your query is not executed a second time) and looks for sequential scans on large tables. When it finds one, the performance item includes a suggestion such as:
Suggestions are derived from the query plan. Treat them as a starting point — review them against your schema and workload before adding an index, since the right index depends on your full query mix, not one check. When the incident diagnosis or a managed-check review proposes a fix, it reads the real schema and existing indexes of the tables your check queries first (introspected on demand and cached per table for a few hours) — so it works from the indexes you actually have rather than guessing, won’t re-suggest one that already exists, and can tell you when the indexes are fine and the slowness is elsewhere (data volume, query shape). If there are no suggestions, the slowness is usually in aggregation, the amount of data scanned, or the database itself rather than a missing index.

​
When Alertee generates checks for you

The AI that drafts checks is performance-aware before a check ever runs. It reads your schema with each table’s size and existing indexes, times its test queries, and runs EXPLAIN (never EXPLAIN ANALYZE — it doesn’t execute your query) on each candidate. From that:
  • An efficient query is suggested normally.
  • A worthwhile check that needs an index you don’t have is still suggested, but with a note telling you the exact index to add first, e.g. “Add an index before saving: CREATE INDEX ON orders (store_id);”. Add the index, then save.
  • A low-value check that would be expensive (a nice-to-have that would scan a huge table every run) is skipped, and the assistant tells you why — so you can ask for it explicitly if you disagree.

​
Keeping checks light

A few things keep the load Alertee puts on your database small:
  • Filter in SQL. A WHERE clause that an index can serve beats scanning a whole table. The suggestions above point at exactly these cases.
  • Aggregate in the query. Return one number (or one row per dimension for a grid check) rather than many rows.
  • Match the interval to the need. A query that takes several seconds doesn’t need to run every minute.

​
Via the API, MCP, and CLI

Performance items are ordinary inbox items with itemType: "performance", so they show up in list_inbox / get_inbox_item (and the CLI). The query duration and any index suggestions are in the item’s sourceMetadata.