Question 1

Who writes and maintains the checks - me or Alertee?

Accepted Answer

Either, and you choose per check. Write a check yourself in plain SQL and it stays yours - Alertee never touches it. Or let Alertee's AI agent author it: the agent inspects your schema, drafts a baseline-aware query, sets a threshold, and then keeps that check tuned for you. Checks the agent owns are marked “managed by Alertee”.

Question 2

What does Alertee do with a check it manages?

Accepted Answer

It owns that SQL end-to-end: baseline-aware queries (window functions, rolling averages, z-scores where appropriate), a chosen threshold, and a re-review on a cadence proportional to how volatile the data is - typically every few days to a couple of weeks. Every review is logged with a before/after SQL diff plus the reasoning, so you can see exactly what changed and why.

Question 3

How is this different from uptime monitoring?

Accepted Answer

Uptime monitors tell you whether something is reachable. Alertee is for the next failure mode: the app is up, but the database says the outcome stopped happening — or quietly went wrong. It checks rows written, stale tables, wrong or invalid values, stuck jobs, failed payments, quiet tenants, and integration state directly with SQL.

Question 4

What can Alertee monitor?

Accepted Answer

Anything you can express as a SQL query against your PostgreSQL or ClickHouse database. Common examples: data freshness, row counts, missing records, stuck queues, failed payments, and gaps for a specific tenant or region. If you can write it as a query, Alertee can watch it and alert you the moment the result drifts.

Question 5

Can I edit a check or take it back from Alertee?

Accepted Answer

Any time. Hand a check you wrote over to Alertee for ongoing tuning, or switch a managed check back to yours and the agent stops touching it. The SQL is always visible and editable - it's the contract between you and the agent, and nothing is hidden.

Question 6

What happens when an alert fires?

Accepted Answer

Alertee opens or updates one data incident, groups repeat failures of the same check together, and sends the configured email or Slack notification. When you resolve it, you can classify the outcome so future reviews know whether the alert was real, transient, expected, noisy, or fixed.

Question 7

What databases does Alertee support?

Accepted Answer

PostgreSQL and ClickHouse today. Databases can be self-hosted or managed (Supabase, Neon, AWS RDS, Google Cloud SQL, ClickHouse Cloud, etc.) as long as they're reachable from the public internet. We only need a read-only user - never write access.

Question 8

Why does the agent need database access?

Accepted Answer

The agent inspects your schema, samples small amounts of data, and tests queries to build calibrated checks. Without read access it would be guessing. Everything happens over a read-only connection, credentials are encrypted per-organization, and you can revoke access at any point by rotating the DB user - no vendor lock-in.

Question 9

Is my data sent to an LLM provider?

Accepted Answer

Query structure and small result samples are sent to Anthropic (or OpenAI as a fallback) when the agent is authoring or reviewing a check. Bulk data is never uploaded. Alertee does not call an LLM on every alert fire; the expensive work happens during deliberate authoring and scheduled review.

Question 10

Databases on private networks?

Accepted Answer

Coming soon. Bastion / SSH tunnel support is on the roadmap. For now the database needs to be reachable from the public internet; a read-only IP allowlist is the usual way teams handle this.

Simple, transparent pricing

Frequently asked questions

Start with one data outcome you should never miss