Automation you can't observe is automation you can't trust. FluidGrids executes every run on a fleet of background workers and records what happened at the resolution that matters: the individual node.
When a trigger fires or someone clicks Execute, the run is queued as a job on the message queue and picked up by whichever worker is free. Execution is fully detached from the client — close the browser mid-run and the workflow completes anyway. Workers scale horizontally as competing consumers: add replicas and they share the load without ever double-executing a job, and killing one worker mid-fleet just shifts its jobs to the survivors.
The executor tracks per-node state as it walks the graph. Parallel branches genuinely fan out and execute concurrently; merge nodes reconverge them with five different merge strategies; and completion detection settles the run only when the whole graph has resolved.
The monitoring surface matches that granularity. The executions list is your filterable triage queue; open any run and the detail view shows each node's status, input, output, logs, duration, and error — live while the run executes, and preserved permanently afterward. "The automation failed" becomes a 60-second diagnosis: which node, what input, what came back.
Operations teams get a real ops surface too: workers expose health and stats endpoints plus operational metrics for jobs processed, succeeded, failed, and in flight. Your workflow platform shows up in the same dashboards as the rest of your infrastructure — because it is infrastructure.
Do it yourself
Watch runs execute on background workers node by node — live as they happen and preserved permanently afterward — completely off the request path.
Open the Runs page to see your filterable triage queue of executions.
You should see: Every run is listed with its status, workflow, and timing.
Ready to make this your story?
