"The workflow failed" is the least useful sentence in operations. The questions that matter are: which step, what kind of failure, and can I recover without redoing everything? FluidGrids answers all three by design.
When a node fails, the executor classifies the failure against a 14-type error taxonomy — authentication, network, validation, timeout, rate-limit, and more — and persists it on that node's state along with the error detail and attempt count. The run list filters by failed status to give you a triage queue; the run detail pinpoints the failing node in the graph.
The error type changes what you do next. An authentication error on the Stripe node? The connection's credential expired — rotate it in the connections screen. A validation error? The upstream payload changed shape — inspect the previous node's output right there in the run detail. You're debugging with evidence, not re-running with fingers crossed.
Recovery is surgical: retry just the failed node. A 30-minute pipeline that died at step 4 of 6 doesn't restart from step 1 — the retry picks up the failed node and continues the run from there. One click, not one re-run, and no duplicate side effects from the steps that already succeeded.
In-flight runs are controllable too: pause a run, resume it — optionally with a payload — or cancel it outright, each operation permission-guarded like everything else. And at the job level, workers acknowledge jobs only on success, so a worker crash mid-run means the message queue redelivers the job rather than losing it. Failures are a workflow state to be managed, not an outage to be mourned.
Do it yourself
Diagnose a failed run from its typed error on the exact node, fix the real cause, and retry just that node so a 30-minute pipeline picks up where it left off.
Open Runs and filter to failed status.
You should see: A triage queue of just the runs that need attention.
Ready to make this your story?
