FlowWatch
Monitoring for automations that die silently
90 seconds: a live automation is killed silently — and caught within two minutes. Nobody touches anything.
The problem
Businesses run on automations — leads, invoices, orders moving between systems. When one fails loudly, you see an error. When it dies silently, nothing happens: no error, no alert, and the dashboard still says "active". You find out weeks later, when someone asks where the leads went.
The label on the screen is an intention, not a fact. It describes what is supposed to happen — not what is happening.
How a silent death plays out
One edited workflow. The same two minutes past two on a Tuesday night. Two very different weeks.
Without monitoring
Someone edits the workflow. The schedule is silently deregistered. The screen still says "active".
Leads keep arriving on the website. None of them reach the CRM. No error is raised anywhere.
Someone asks: "why did nobody follow up with that lead?"
~40 leads never answered. Discovered by accident.
With FlowWatch
The same edit. The same silent death.
🔴 Slack alert: "An automation stopped running — and no error was raised", including what changed and when.
The workflow is switched back on. ✅ The system closes the issue by itself.
Total blind time: 2 minutes.
An illustrative scenario. The incidents under "Built on real failures" below are the ones that actually happened.
What it does
Detects silent death within two minutes — by checking when each automation actually last ran, never by trusting the "active" flag.
Alerts in plain language: "An automation stopped running — and no error was raised." The raw error text is pushed down to a technical footnote.
Points at the cause: "Broken since the workflow was edited on Aug 22" — based on the version that actually runs, not the draft.
Closes the loop by itself: groups repeats into one alert instead of two hundred, and sends a single all-clear when things recover.
Built on real failures
During development, the platform reported "active" three times while the schedule was silently dead. That is the exact failure the system was built to catch — and it happened in-house before it ever happened at a client.
And once, on camera while filming the demo: the automation was switched off — and kept running for another minute. The screen said "off" while the work continued. The gap between the label and the truth goes both ways, and that gap is where businesses lose money without knowing it.
Under the hood
Four engineering decisions, and what each one buys you:
Never trust the status flag
The platform reported "active" while nothing ran — three times. So health is derived only from real execution timestamps.
The dashboard can't lie to you, because we never ask it.
A false alarm is worse than a missed one
When the monitor itself cannot read data, it stays silent instead of declaring everything dead.
Three wrong alerts and nobody reads the fourth — the real one.
Blame the version that runs, not the draft
Correlation uses the published version's timestamp — the platform keeps two dates per workflow, and the wrong one can be hours off.
"What broke it" is only useful if it's true.
Every decision is testable
Overdue, severity, cooldown, correlation — pure logic isolated from I/O, covered by 103 unit tests.
The alert you get at 2 AM was decided by code that is proven, not hoped.
Pure decision logic (overdue, severity, cooldown, correlation) is isolated from I/O and covered by 103 unit tests.
Running automations in your business?
Ask yourself what proves — right now — that all of them are alive. If the answer is "they're marked active", that isn't proof.