Automated reports and alerts from your databases and apps.
Write a query against your own company data, then point a rule at it. A report runs on its schedule and lands in the Portal the moment it fires, then posts on into Slack, Google Chat, Discord, Telegram or email as you scale up — as the plain figures, or narrated in English by Nova. An alert watches those same numbers continuously and speaks only when one crosses a bound you set. Revenue, stock levels, prices, failed payments: if a query returns it, a rule can watch it.
On every plan · limited on Free and Personal, full on Business & Enterprise
Two kinds of rule. One saved query.
Both run your query on a schedule. What they do with the result is the whole difference — and it is easier to see than to read.
Schematic diagram — illustrative, not a screenshot or measured data.
Alert — speaks only when something goes wrong
Take the number your query already returns and say what wrong looks like. While things are fine you hear nothing at all. The moment it goes wrong you get one message, at the severity you chose — and you are not pinged again every run while it stays wrong. When it comes right, one more message tells you so, so you know it’s over without going to look.
- Above or below the level you set
- Row-count checks — too many, too few, none at all
- Change versus the last run
- Severity:
critical·warning·info
Report — arrives on schedule, in your channels
The schedule fires, the query runs, and the results land in the Portal straight away — then post on into the places your team already talks, Slack, Google Chat, Discord, Telegram, email, as you scale up. Nothing is generated to download and nothing is attached: the report is the message. Send it as the plain figures, or let Nova narrate what the numbers are doing.
- Runs whether or not anything changed
- Can hold a run back when there’s nothing to say
- Plain figures or Nova-narrated — your choice
- Every run keeps a link back to that run in the Portal
Almost none of this is about the database
It is revenue, stock levels, prices, payments — and the quiet table that means something upstream broke. The database is just where the answer happens to live.
Threshold alerts, on any number your query returns
Threshold monitoring is the simplest useful rule there is: take a number your query already returns, give it a bound, and say what counts as wrong. Above the bound. Below it. Or moved by more than you’d expect since the last run.
The rule has no opinion about what the number means. Yesterday’s revenue, units left in the warehouse, a unit price, the count of failed payments in the last hour — they are all just a value and a bound. You supply the judgement; the rule supplies the patience.
Pair a threshold with a severity and the same number can speak at two volumes: a warning when it drifts, critical when it goes badly wrong.
-- The kind of query you already have. A rule points at it; it doesn't rewrite it.
SELECT c.name AS channel,
COUNT(*) AS orders,
SUM(o.net_total) AS revenue
FROM sales_orders o
JOIN channels c ON c.channel_id = o.channel_id
WHERE o.order_date >= CURRENT_DATE - INTERVAL '1 day'
AND o.status <> 'cancelled'
GROUP BY c.name
ORDER BY revenue DESC;Illustrative — your tables, your business logic, your saved query. Put a bound on revenue and it becomes a threshold alert. Give it a weekly schedule and it becomes the Monday morning post in Slack. Same query either way; we don’t ship it, and we don’t change it.
Automated sales reports, daily or weekly
A daily sales report at seven in the morning and a weekly sales report every Monday, delivered where your team already reads things. One saved query, two schedules, no spreadsheet handoff.
Then point an alert at the same query for the other direction: tell me when a day’s revenue lands below the number I set, rather than making me wait until Monday to find out.
Low stock alerts, and the stock that never moves
Watch units on hand against a reorder point and get a low stock alert while there is still time to do something about it — from your own warehouse tables, or from Shopify through the API connector.
Run the idea backwards for the opposite problem: inventory alerts for the lines that haven’t moved in ninety days and are quietly sitting on your cash.
Price monitoring on the data you own
Point a rule at price data you already hold in a connected source — your catalogue, your rate card, a supplier feed you import — and hear about it when something changes or crosses a bound.
To be clear about the boundary: we read the sources you have connected. We do not scrape anyone else’s website for their prices.
Market data, watched against a level you choose
Our iTick connector brings market data in as queryable rows, so an instrument’s price is simply another number a rule can watch — above a level, below one, or moved more than you expected since the last run.
It is an alerting tool, not a trading one. You get the notification; nothing places an order.
Failed payments and orders that stalled
Count the payment failures Stripe recorded in the last hour, or the orders sitting unfulfilled past the point you’re comfortable with, and trigger when the count crosses what you would tolerate.
Then the recovery notice tells you when it is back to normal — which is the half most alerting leaves out.
The pipeline that went quiet
A table that stops receiving rows is usually the first visible sign that something upstream broke — an integration expired, a nightly job stopped, a feed changed shape and nobody noticed.
A row-count rule or a change-since-last-run rule catches that on a schedule, and reports it in business terms: no orders have landed since four this morning.
KPI monitoring, without opening a dashboard
Most data monitoring software asks you to go and look at it. This asks nothing of you at all until a number you care about moves.
Illustrative schematic — four KPIs, one bound each. Only the one that crossed says anything.
A KPI is just a number a query returns. Gross margin, conversion rate, days of stock cover, the age of the oldest unshipped order, churn so far this month — if you can express it as SQL, you can put a bound on it and hand it to a rule. There is no separate metric layer to define it in first, and no dashboard you have to build before anything can watch it.
You choose the bound, and you choose the cadence: nightly, hourly, weekly, or as often as every five minutes. When the number crosses, the rule speaks through whichever channels you picked, at the severity you set. When it comes back, the recovery notice tells you so.
That is the honest scope of it. This is not a BI tool and it is not trying to replace your dashboards — it is the layer that tells you to go and look at them. Where most data monitoring tools are somewhere you have to go, this is something that arrives.
If a saved query can reach it, a rule can watch it
Alerts and reports have no private idea of what a data source is. A rule points at a saved query, and that query travels the same connector path every other query on the platform travels. So the rule inherits your entire source list rather than some subset of it.
That is 11 databases — SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Snowflake, BigQuery, SQLite, Access and DuckDB — plus 8 API connectors: Stripe, HubSpot, Shopify, Google Analytics 4, Google Ads, Search Console, ShipStation and iTick. 53 sources, all equally watchable. Failed payments from Stripe, stock levels from Shopify, a traffic collapse in GA4, an instrument price from iTick.
And because the feature borrows the connector layer instead of reimplementing it, a connector we add later works the day it ships — nothing to update in alerts, nothing to switch on.
The practical upshot. You are never picking from a menu of what we thought to support. You write the query against whatever the business runs on, and the rule follows it.
Three steps to an automated report
You are not learning a new query language. A rule borrows a saved query you already trust — its SQL, its connector and its filters.
Point it at a saved query
Open Automation → Alerts & Reports and pick a query from your Query Builder library. The rule reuses that query, its connector and its filters — nothing to rewrite.
Choose alert or report
An alert needs to know what wrong looks like: a level to stay above or below, a row count, or a change against the last run. A report just needs a schedule — the condition is optional there.
Choose how it reaches you
It reaches the in-app bell on every plan, and fans out to any mix of the seven channels as you scale up — email, Slack, Google Chat, Discord, Telegram, a signed webhook. Set the severity, and choose whether it sends the plain figures or a Nova narration.
Not sure what to watch? Ask Nova.
Most people know they want reports before they know which query to report on. So there is a second way in: choose the connector you care about — the picker shows you which of your databases already have Schema Intelligence coverage — and let Nova propose the rules.
Nova reads your real schema, then does the part that matters: it runs exploratory read-only queries to confirm the data is actually there and actually populated. Only then does it suggest concrete alerts and reports, named for your tables and your columns. It doesn’t guess from table names — it checks first.
What Nova does before it suggests anything
- Reads the schema. Tables, columns and types as they exist right now — enriched where Schema Intelligence has run.
- Runs exploratory queries. Read-only probes against the live data, through the same validator as everything else:
SELECT,WITH,EXPLAIN. - Confirms the data is populated. A column that exists but is empty makes a useless alert. Nova finds that out before you do.
- Proposes the rule. Concrete alerts and reports for your tables, with the condition, the schedule and the severity already filled in — yours to accept or edit.
Nova is included from Business plans upward, and is usage-based: monthly Nova credits included, then pay-as-you-go.
Seven places a data alert can land
Every rule lands in the Portal’s in-app bell to begin with, and reaches out into the tools the business already communicates in as you scale up. One rule can fan out to as many of them at once as you like.
Slack
Discord
Google Chat
Telegram
In-app notifications land in the bell in the Portal top bar, and clicking a report notice opens that run — every run keeps its own permanent link, so you can hand a colleague the page rather than forwarding anything. Email goes out per recipient and is tracked per recipient, so the rule can show you who has actually seen it.
Slack alerts, Discord alerts, Google Chat and Telegram each get a message built for that platform rather than a lowest-common-denominator one. Discord deliveries are real Discord embeds, and every payload sets its allowed mentions explicitly — so a rule cannot accidentally notify your whole server at three in the morning. Google Chat adds stable threading: repeat notifications for the same rule land in one thread instead of starting a new one each time. That is a Google Chat advantage specifically; Slack and Discord webhooks can’t do it.
Webhooks are signed, so your receiver can verify a delivery genuinely came from us before acting on it, and outbound targets are validated before we call them.
Or let Nova write the report
Switch narration on and the report stops being a table and starts being a briefing. Nova reads what the run actually produced and writes a short summary in English of what is happening — covering your sales, or your stock, or whatever you pointed it at, the way a reporter covers a beat.
And the query is the seed, not the boundary. If the story needs context those rows cannot give — per-item rates from a movements table, how this week compares by category, which items actually moved — Nova goes and finds out. It reads a digest of your schema, writes its own read-only follow-up queries against the same connection, and only then writes the summary. You decide how far it may go: one round for a quick read, up to five for a deep dive.
This is a different job from the Nova that helps you build the rule in the first place. That one designs the rule before it exists. This one covers the rule’s results run after run — and researches around them when the story needs it.
The figures are the floor, and the floor never moves. The numbers, the rows and the series are assembled first and always send. Narration is added on top of them — and if it fails for any reason, the report still goes out with the figures intact. It cannot delay a delivery and it cannot block one.
Because Nova compares each run against the ones before it, a change arrives as a sentence rather than as a number you have to diff yourself. And it is set per rule: some reports want the prose, some want the bare figures at a glance. Both are legitimate, and you choose.
You set the depth on the rule — up to five rounds, each up to two read-only queries, asking for aggregates and top-N rather than dumps. Nova stops early when a thread is no longer earning its keep, and skips exploring altogether when the seed already tells the story. Narration is included from Business plans upward, and is usage-based: monthly Nova credits included, then pay-as-you-go.
Your data stays where your data lives
Scheduled or not, a rule runs the same way every other query on the platform runs.
Outbound-only Network Agent
The Agent opens one encrypted outbound connection and carries requests and results both ways over it. No inbound port, no VPN, no firewall change — and your credentials never leave your network.
Read-only, validated
The same validator that guards every other query guards these: only SELECT, WITH and EXPLAIN get through. A scheduled rule cannot write to your database.
Role-gated by design
Managing rules is limited to the organization creator, admins and query managers — because a rule that mails data out is a permission, not a preference.
Reached through the Agent: SQL Server · PostgreSQL · MySQL · MariaDB · Oracle · Snowflake · BigQuery · SQLite · Access · DuckDB · Stripe · HubSpot · Shopify · Google Analytics 4 · Search Console · ShipStation · iTick
Automated reporting FAQ
What is the difference between an alert and a report?
An alert evaluates a condition against your query’s results on a schedule and only notifies you when that condition breaks. It has a lifecycle: it triggers, the incident stays open, and you get a recovery notice when it clears. A report fires on its schedule every time and posts the results into your channels — no incident lifecycle. You can still attach a condition to a report, but there it acts as a send filter: only send this if there is something in it.
Can I get a sales report in Slack every Monday morning?
Yes — that is a report rule. Point it at your sales query, give it a weekly schedule, and tick Slack as a channel; add email, Discord, Google Chat or Telegram alongside if different people read in different places. Every rule reaches the in-app bell whatever your plan, and the chat channels come in as you scale up — Slack itself on Business plans. If you also want to hear about a bad day without waiting for Monday, add a second rule as an alert with a threshold on the same query.
Do I have to write new SQL to schedule a report?
No. A rule points at a saved query you already have in the Query Builder and reuses it — the SQL, the connector and the filters. There is no separate rule language to learn, and the rule never rewrites your query. If you don’t have one yet, write it in the Query Builder or ask Nova to read your schema and propose both the query and the rule.
How do scheduled reports reach my team?
Up to seven channels, in any mix per rule. The in-app bell in the Portal top bar is there on every plan; email (delivered and tracked per recipient, so you can see who has seen it), the chat channels — Slack, Google Chat, Discord, Telegram — and signed webhooks come in as you scale up, with the full set on Business plans. There is no PDF and no attachment — the report is the message itself, posted where your team already talks. Each run also keeps a permanent link back to that run in the Portal, so you can hand someone the page instead of forwarding a copy.
Do I get raw numbers, or something readable?
Either, per rule. The figures — the rows and series your query returned — are always built first and always send. On top of that you can switch on Nova narration, which reads what the run produced and writes a short English summary of what is happening, comparing against previous runs so a change arrives as a sentence rather than a number you have to diff yourself. If narration ever fails, the report still goes out with the figures; it can delay nothing and block nothing. Narration is included from Business plans upward, and is usage-based: monthly Nova credits, then pay-as-you-go.
What can a threshold alert actually check?
Thresholds on a tracked value, row-count checks, and change versus the last run — all evaluated against the results your query returns. So the number can be revenue, a stock level, a price, a count of failed payments, or anything else a SELECT can produce. Each rule carries a severity of critical, warning or info, which drives how loudly the notification presents itself. This watches the business data in your query results; it is not a server-health or infrastructure tool.
Which sources work, and who can set rules up?
All of them. A rule watches a saved query, and a saved query can target any of the 11 databases — SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Snowflake, BigQuery, SQLite, Access and DuckDB — or any of the 8 API connectors: Stripe, HubSpot, Shopify, Google Analytics 4, Google Ads, Search Console, ShipStation and iTick. Connectors added in future work the day they ship, because alerts use the shared connector path rather than their own. Managing rules is role-gated to the organization creator, admins and query managers, under Automation → Alerts & Reports.
Stop going to look. Let it tell you.
Pick a saved query, choose a schedule or a threshold, and let the report come to you — or let Nova read your schema and suggest the first few.
On every plan · limited on Free and Personal, full on Business & Enterprise
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish