This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle
What I Built
Imagine running a small business where your inventory updates automatically, customer notifications go out through workflows, and different tools stay in sync without you having to do everything manually.
Now imagine one API fails.
An order doesn't get processed. Inventory stops updating. A customer never receives their notification. And suddenly, you're spending time digging through logs instead of running your business.
For a small business, even a minor automation failure can turn into a frustrating operational problem.
That got me thinking: what if there were a system that could detect these failures, figure out what went wrong, and safely handle recovery whenever possible?
That's the idea behind REBOOTX.
I built it as an open-source, self-hosted automation recovery engine that currently integrates with n8n. I focused on getting the components to work together, testing the recovery flows, and making the system easier to run locally.
Demo
📥 GitHub Release: Install REBOOTX
🎥 Video Demo: See it in action
Code
sakshammalik260-cse
/
Rebootx-ai
REBOOTX — An open-source AI-powered automation recovery engine that detects failed workflows, diagnoses errors using Gemma, and autonomously executes safe recovery strategies with Temporal.
💜 REBOOTX — Automation Recovery Platform
When automations break, recovery shouldn't be guesswork.
Small businesses and developers depend on automation every day. But when an API fails or a workflow stops working, fixing everything manually can take time.
REBOOTX is an open-source, self-hosted platform that helps detect failures, manage recovery attempts, verify results, and keep a record of what happened.
Instead of blindly retrying everything, REBOOTX combines recovery workflows, safety checks, and outcome verification to make automation failures easier to handle.
⚠️ Current status: Mock recovery is enabled by default. Real n8n recovery is optional and is still partially implemented. REBOOTX does not automatically fix every failure.
✨ What can REBOOTX do?
- 🔎 Detect failures — Receive alerts when an automation fails.
- 🧠 Diagnose problems — Use rule-based checks and AI-assisted diagnosis.
- 🔄 Manage recovery — Coordinate recovery steps using Temporal.
- 🛡️ Apply safety checks — Check permissions and rules…
How I Built It
Here's the high-level architecture:
n8n → FastAPI → PostgreSQL + Transactional Outbox → Temporal → Recovery Worker→ Verification → Dashboard
Each component handles a different part of the incident lifecycle.
Separating these responsibilities makes the system easier to reason about and gives each component a clear job.
The Tech Stack Used
End-to-end incident lifecycle
For failure to recovery, in 8 steps:
Security, safety, and tenancy
Tenant authentication: Read tokens are securely hashed before storage in PostgreSQL.
Webhook security: HMAC-SHA256 protects incoming events; secrets stay in environment variables.
Data isolation: Tenant-scoped operations and idempotency controls protect data and prevent duplicate processing.
Safe defaults: Mock recovery and mock AI are enabled by default.
Controlled changes: Real n8n workflow changes require explicit authorisation and fingerprint matching.
Credential protection: .env files and runtime credentials are excluded from version control.
Known limitation: Temporal’s internal-network TLS exception needs hardening before exposure to untrusted networks.
What has actually been built and verified?
The checkpoints:
Simulation, test and verification report | v0.1.0 | 18 October 2026:
These results gave me confidence that the core incident-to-resolution pipeline was working in the tested environment.
There is an important limitation, though: one recovered incident out of two simulated scenarios is not a meaningful estimate of real-world recovery performance. We deliberately selected the scenarios to test different paths.
The project still needs broader load testing, failure-infrastructure testing, independent security review, and clean-install verification on another machine before I can make stronger claims about production readiness.
I would rather be clear about those limitations than claim that a successful test suite proves everything is ready for production.
[Insert Image 4: A screenshot of your actual terminal showing the backend and frontend test results, with any secrets or personal paths hidden.]
Why Does Open Innovation Matter?
Small businesses should not need expensive enterprise software to manage automation failures.
Open innovation makes my approach possible. Developers can inspect the code, contribute improvements, extend integrations, and adapt the system to different business needs instead of depending on a single proprietary solution. Docker Compose also makes self-hosted deployment more accessible.
Prize Categories
Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle
Best Use of Temporal — REBOOTX uses Temporal to orchestrate durable recovery workflows, track execution, and coordinate incident recovery.
Best Use of Gemma — REBOOTX includes a Gemma diagnosis-provider integration path for AI-assisted failure analysis. The default configuration uses a mock provider.
Team Members
@saksham_malik_2606 for ideating and building it.
Top comments (0)