Your database already knows. Now your team will too.
RowFire turns what happens in your database into Slack messages, Zendesk tickets and API calls. Engineering describes an event once, in SQL. Support, billing, sales and growth subscribe to it — without filing a ticket for every automation.
No sign-up. The demo runs on sample data and delivers to a built-in inbox.
SELECT a.id AS account_id, a.name AS account, a.owner_email, pa.invoice_no, pa.amount, pa.attempted_at FROM payment_attempts pa JOIN accounts a ON a.id = pa.account_id WHERE pa.status = 'declined'
Card declined for Kite Labs — INV-5 ($49.00, expired_card).
Payment failed for Kite Labs. Hi Femi, could you update your card?
The problem
Every "tell us when this happens" becomes an engineering ticket.
The data is already in your database. But each alert, each follow-up, each "open a ticket when…" means application code, a deploy, and a queue behind the roadmap. So most of them never get built.
- Billing"Ping us when a card is declined — but not three times for one invoice."
- Sales"Post in #sales when an Enterprise account signs up."
- CS"Open a ticket when a trial ends in three days and never activated."
- Support"Escalate urgent tickets nobody has answered."
- Growth"Follow up with every NPS detractor, once a month at most."
Why RowFire
Engineering defines the event once. Everyone else ships on their own.
The split follows who knows what: whoever knows the schema writes the query, and whoever owns the customer experience decides what happens and how often.
No engineering queue
Teams pick an event, say how often it may fire, attach an action and switch it on. Many rules can subscribe to one trigger.
Nothing changes in your app
No application code, no new service to deploy, no change-data-capture. RowFire reads with a read-only query and never writes to your database.
See it before it sends
A backtest replays a rule over the last N days. Shadow mode renders every real request without sending it. Promote when the numbers look right.
No duplicate noise
"Once per account per week" is a setting, not code. Three declines on one invoice are one billing problem, and customers hear about it once.
Any destination
Slack, Zendesk and Braze out of the box, or any REST API. Integrations are configuration, and templates pull any column with {{ column }}.
All your databases
PostgreSQL and MySQL, as many as you have. Each trigger names the one it reads, so the app database and the support desk work side by side.
How it works
Three pieces, each owned by the person who knows it.
Describe the event as SQL engineering
A trigger is one SELECT. Join anything, compute anything, then pick which column is the clock and which columns make a row "one thing".
- Checked as you type: the columns it returns, aliases included
- Written in each database's own dialect
- Polled once, its rows fanned out to every rule on it
Subscribe a rule and backtest it support, billing, sales, growth
Pick the trigger, set how often one key may fire, and ask what it would have done. Here, 219 declined charges over 120 days become 107 tickets — 112 duplicates that never reach a customer.
- Once ever, once per period, or every nth time
- Example rows show exactly who would have been contacted
Attach an action, watch it in shadow, promote
Choose Slack, Zendesk, Braze or your own API, and write the message with the trigger's columns. New rules run in shadow: every request is rendered and recorded, nothing is sent. When it looks right, promote it to live.
- A stop-everything kill switch
- Every poll recorded, so "nothing happened" is distinguishable from "nothing ran"
From the demo
The backtest catches what a review would miss.
Real numbers from the sample SaaS company in the live demo, over 120 days of data.
Declined charges turned into Zendesk tickets by "once per account per week". The other 106 were retries that would have been duplicates.
Enterprise sign-up posts to #sales, naive query vs corrected. The backtest's example rows showed internal QA tenants slipping through.
Workers that would send when 16 race for the same row. A fire is claimed in the database first, so one event is one send.
Safety
Built to sit next to production data.
RowFire reads your database the way a reporting tool would, with more guardrails than most.
- Read-only, three ways. Read-only sessions, a parser that refuses anything but a single
SELECT, and the account you grant it. - What was checked is what runs. Queries are re-rendered from the validated syntax tree, with a statement timeout and a row cap.
- Credentials encrypted at rest. Secrets are applied at send time and never shown again after you save them.
- History never fires. Triggers start at "now", so switching a rule on doesn't replay last month.
- Versioned definitions. Every change is kept, and editing a live rule sends it back to shadow.
- Yours to run. Self-host it inside your own network. Open source under the AGPL.
See your first rule fire in five minutes.
The live demo gives you a private workspace on a sample SaaS company: two databases, seven ready-made rules, and a Demo inbox that shows what Slack and Zendesk would receive.