# FlowMedic: Investigating Broken Automations Before You Hit Retry > Source: > Published: 2026-10-19 05:04:04+00:00 *This is a submission for the [Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle](https://dev.to/challenges/hacktoberfest-week2-2026-10-12).* **An order-creation workflow times out. Do you retry it?** The workflow stopped receiving a response, but the remote system might already have created the order. Another attempt could create a duplicate. That uncertainty is the problem behind **FlowMedic**, an AI-powered failure investigator for freelancers and small agencies maintaining n8n automations. These operators connect the systems businesses depend on: lead forms, CRMs, invoices, orders, and customer notifications. When something breaks, they need to reconstruct what happened, explain it to a client, and choose a sensible next step. FlowMedic brings that investigation into one workspace. It receives an n8n failure event, gathers available evidence, and uses **Gemma running locally through Ollama** to produce: The dashboard combines those findings with execution details, an investigation timeline, and an audit history. The intended customer is a freelancer or agency responsible for roughly **5–50 workflows**. My initial pricing hypothesis is **$29/month for a solo workspace**. The value to validate is having useful investigation context and recovery decisions in one place. I haven’t established willingness to pay, implemented billing, or measured customer time savings. Those are questions for customer validation rather than claims about the MVP. FlowMedic currently runs locally. The repository includes setup instructions and three reproducible scenarios that exercise the application pipeline. An HTTP 429 response includes a retry delay. FlowMedic investigates the evidence and offers a human-approved, bounded demo retry. The receiving step expects `email`, while the incoming payload contains `email_address`. The evidence helps the operator inspect the mapping. Replaying the unchanged workflow remains blocked. The request body was sent, but its remote outcome is unknown. FlowMedic flags the uncertainty and blocks blind retry. The scenario failures and executable recovery adapter are simulated. **Model inference, database persistence, Temporal orchestration, and operator decisions are real.** I also verified the integration against a local **n8n 2.43.7** instance. A production webhook deliberately failed, its Error Workflow delivered the event, and FlowMedic fetched permitted workflow and execution evidence before running a Gemma investigation. This post includes the repository and local reproduction instructions; it does not include a hosted application or video walkthrough. The repository includes the application, importable n8n examples, scenario fixtures, setup instructions, model evaluation reports, and verification notes. FlowMedic’s source is MIT licensed. Model weights and dependencies retain their respective licenses. FlowMedic is a **TypeScript pnpm monorepo** built with: **First, n8n reports a failure.** FlowMedic authenticates the delivery, redacts common secrets, normalizes the event, and stores it in PostgreSQL. A database uniqueness constraint protects against duplicate deliveries. **Next, Temporal coordinates the investigation.** Five typed, read-only tools gather execution details, workflow metadata, failure context, related incidents, and retry-policy evidence. **Mastra then calls Gemma with the gathered evidence.** The backend explicitly runs the tools before generation; it does not assume Gemma supports native function calling. Native structured output and Zod validation constrain the diagnosis format. **The diagnosis and recovery proposal are persisted.** The dashboard shows the explanation, supporting evidence, missing information, and proposed next step. **Finally, the workflow waits for a human decision.** The backend independently checks recovery eligibility. A model recommendation cannot authorize a retry. Only eligible demo cases can execute the simulated recovery adapter; live n8n retries remain disabled. Temporal handles activity retries, backoff, and the approval wait. A verified worker-restart test showed an investigation continuing with its existing diagnosis and completing one simulated recovery. The verification log records **53 passing automated tests**, successful typechecks and a production build, alongside actual model-backed scenario runs. I compared Gemma 1B and 4B using the same three fixed evidence inputs. Both passed every behavioral probe in two of the three scenarios, but they failed differently. The smaller model omitted an expected field name; the larger model identified both fields but failed a retry-recommendation check. The real n8n test exposed another limitation: the model recognized the deliberate failure but also suggested an unsupported webhook problem. Those results remain documented. **Schema-valid output can still contain an incorrect explanation.** That is why FlowMedic exposes the evidence and keeps recovery authorization outside the model. I used Codex to help implement, test, and iterate on the project. Automation logs can contain client information. Running Gemma locally gives an operator control over where investigation evidence is processed, without requiring a proprietary model API. Open weights also let me compare model sizes on my own machine and inspect the tradeoff between runtime and output quality. The configured model and endpoint can change without replacing the surrounding incident workflow. Mastra and Temporal make the orchestration inspectable too: how evidence is gathered, how generation is validated, what happens when an activity fails, and how a human decision reaches a waiting investigation. Local inference does not make the system free to operate. Hardware, electricity, hosting, and maintenance still matter. It does provide a path to running the core investigation without a required per-request commercial model bill. The current application is a trusted local, single-operator MVP. Public authentication, multi-tenancy, billing, and live n8n recovery remain future work. My next validation step is to put it in front of an automation freelancer and watch them investigate a failure from their own workflow.