We just confirmed all 5 detection rules working in production — opening free beta soon
Hey IH,
I've been building OrchestrAI for the past few sprints and wanted to share a milestone + opening up beta access soon.
What is it?
OrchestrAI is an Automation Ops platform — a control layer that sits above your n8n and Make.com automation workflows. It monitors them, detects silent failures, and (soon) auto-retries.
The core insight: most automation tools are great at helping you build workflows. Nobody helps you operate them reliably at scale. That's the gap we're filling.
What we shipped this sprint:
Backend: Node.js + Express on Cloud Run, Firebase Auth, Firestore, Google Secret Manager for API key storage. All integration credentials are stored securely — no plaintext keys anywhere.
Monitoring engine: A Cloud Run service that polls every 5 minutes and evaluates 5 detection rules against every active workflow:
- Hard Failure — execution errored
- Execution Silence — workflow hasn't run in longer than expected cadence
- Success Rate Drop — 7-day rolling success rate below 80%
- Duration Spike — recent executions taking 2x+ longer than baseline
- Output Volume Anomaly — items processed dropped 50%+ below baseline
All 5 confirmed firing in production with correct alert creation, cooldown logic, and health_status updates in Firestore.
CI/CD: GitHub Actions auto-deploys to Cloud Run on every merge to dev.
Stack:
- Frontend: React (7 screens)
- Backend: Node.js, Cloud Run, Firestore, Firebase Auth
- Monitoring: Cloud Run service + Cloud Scheduler (every 5 mins)
- Infrastructure: GCP, Secret Manager, Workload Identity Federation
What's next:
- Email (SendGrid) + Slack alert delivery
- Make.com adapter
- Auto-recovery engine
- Dependency graph visualisation
- Beta user onboarding
Looking for beta users:
If you run n8n or Make.com workflows — especially for client work or business-critical processes, I'd love to have you as a beta user. Free access, and your feedback will directly shape the product.
Drop a comment or DM me here.
Happy to answer any questions about the build, the stack, or the market.
Interesting build.
The thing I'd be careful with is assuming the challenge is finding beta users.
The harder decision may be which automation operator should feel this pain strongly enough to care before a failure actually costs them money, clients, or trust.
That sounds subtle, but it changes who the first customer is, what proof matters, and how the beta should be framed.
I wouldn't make that decision casually in-thread because it tends to shape the entire acquisition path.
You're right I would say and this is something I've been thinking about deliberately.
The framing I keep coming back to is agencies and ops-heavy SMBs running automation for client work or revenue-critical processes. For them a silent failure isn't just a technical inconvenience, it's a client relationship or a missed payment. The cost is real and visible before they even open a dashboard.
That's different from a solo founder whose workflow breaks and they just notice later, or an enterprise team with dedicated monitoring already in place.
The beta is designed to surface exactly this I'm less interested in volume and more interested in finding 5 people where a failure would genuinely hurt them. Their feedback will shape whether the product earns the right to a wider audience.
Would be curious your take on which signal matters most at this stage, is it the operator feeling the pain, or the person accountable when something breaks downstream?
Possibly, but that's exactly why I stopped short earlier.
I don't think the interesting part is choosing between those two signals.
I think it's the decision sitting underneath that choice.
I'd be careful answering that casually in a thread.
If you'd like the tighter version, drop your email and I'll put it together properly.
Appreciate that alot and I take the point. Some decisions shouldn't be made in a thread.
[email protected]
Looking forward to it.
Perfect.
I send it over.