One Broken API Can Disrupt a Business. So I Built Something to Help.

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 — Autonomous Automation Recovery Platform

REBOOTX detects, diagnoses, orchestrates recovery, and audits failures across connected automation engines (such as n8n).

Architecture & Completed Checkpoints

1. Checkpoint 1 — Secure Backend Foundation: FastAPI, Neon PostgreSQL & SQLite support, Alembic migrations (0001–0003), exact-byte HMAC-SHA256 authenticated webhook ingestion, and immutable audit logs.
2. Checkpoint 2 — Temporal Recovery Orchestration: Durable Temporal workflows (IncidentRecoveryWorkflow), transactional outbox dispatcher with leased claiming, retry/fallback execution, and deterministic idempotency.
3. Checkpoint 3 — Google Gemma 4 AI Diagnosis: Structured failure diagnosis using gemma-4-26b-a4b-it via Google Gen AI SDK, conservative deterministic fast-path classification, strict 7-field Pydantic schema validation, and fail-closed safety policy enforcement.
4. Checkpoint 4 — n8n Automation Engine Integration: Native n8n Error Trigger integration, zero-dependency dual-engine HMAC-SHA256 signing (Node.js crypto with pure JS fallback), and live verified end-to-end failure ingestion.
5. Checkpoint 5 — Premium Dark SaaS Dashboard: Production-ready React 18, TypeScript, and Vite dashboard…

View on GitHub

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.