Hey everyone,
I kept running into two problems with my production n8n workflows that the native dashboard doesn’t fully solve:
Problem 1 — AI cost is invisible
I had no idea which workflows were burning through my OpenAI/Anthropic budget until the bill arrived. Native execution logs show runs, not cost.
Problem 2 — Silent failures
A scheduled workflow stopped running. No error, no alert — just silently dead. I found out days later.
So I built a small tool that connects to your n8n instance via API and:
**•** Shows AI/API cost per workflow per run
**•** Alerts you (email or Slack) when a workflow misses its expected run window
It’s completely free right now. I’m not selling anything — I just want to get it in front of real production users and hear what’s broken, missing, or useless.
If you run n8n in production and want early access, reply here or DM me. I’ll onboard you personally.
Happy to answer any questions about the implementation too.
The cost-per-workflow view is a good idea, especially for AI-heavy client work where the invoice shows up long after the architecture decision was made.
One thing I would add is treating cost anomalies like operational events, not just analytics. For example:
- Cost per successful business outcome, not only cost per execution.
- Alert when cost rises but output volume does not.
- Alert when a model fallback changes cost or latency.
- Link the anomaly to the workflow owner and client.
- Keep a short resolution note: prompt changed, model changed, retry loop fixed, rate limit handled, etc.
The silent-failure side and the cost side are connected. A workflow can look “up” while retrying too often, returning bad output, or spending 4x the expected amount to produce the same result. For agencies, that becomes a maintenance/reporting issue pretty quickly.
This is close to the operating layer I am working on with Maintain Flow: checks, issues, resolutions, and client-ready reporting after workflows are live.
You said a workflow stopped running with no error, no alert, and you only found out days later. I hit the mirror image of that last month.
I audited an enrichment tool I’d been using. 183 domains in, 489 phone numbers out. 333 of them (68%) were unusable. A company registration number sitting in a phone field, npm build strings in an email field. Every run completed. Nothing errored. 40% of that garbage survived all the way into the final list I was actually calling, and I didn’t notice for 50 days.
On both of the things you track, that run looked fine. It finished, and it didn’t cost more than expected. It was still wrong.
So my question is about before you built this. Did you ever get a run that came back clean, no error, cost normal, where the output itself was unusable, and you only found out much later downstream? How did you end up catching it, and how long did it take?
@Paul_Fdz — that’s exactly the case cost/uptime monitoring structurally can’t catch, because by every metric that run was healthy. The only way to catch ‘succeeded but wrong’ is a check that inspects the actual output against an expectation before anything downstream trusts it — read-back, or a policy check on the fields that matter, before the result propagates. Jay’s tool and something like that are complementary, not overlapping — his catches ‘did it run and what did it cost,’ the other catches ‘was what it produced actually right.’ Same root problem though: n8n calling something a success only means the call didn’t error, not that the outcome was correct.