Run History, Inspection and Recovery
Follow every workflow execution node by node, then retry, resume or approve runs from a desktop or a phone.
These images are illustrations of the concept, not screenshots of the actual product.
Overview
Every time a FluidGrids workflow executes, it produces a run: a record of which version ran, what started it, how long each node took, what data passed through and what was logged along the way. This concept illustrates the Runs area as the place where a team follows those executions, works out what happened in any one of them, and gets a stalled or failed run moving again without rebuilding the workflow.
Background automations tend to fail quietly. A token expires, an upstream service rejects a request, or a process waits on a decision nobody noticed, and the first sign is often a customer asking why an invoice never arrived. The design answers that by making each run observable down to the individual node, and by placing the recovery actions next to the evidence instead of in a separate tool.
The runs list opens with summary tiles for runs today, success rate, average duration and failures, a filter bar for status, workflow, trigger and date range, and a table in which every row carries a run ID, trigger type, status pill, start time and duration. Opening a completed run shows three panels side by side: an execution timeline of nodes with their timings, the selected node's input and output as JSON, and a timestamped log stream tagged by level and node. A failed run marks the broken node in red, shows a typed error with its message and context, skips the downstream nodes, and offers Retry node, Resume run and Cancel run. A run paused at a wait step shows a Resume run panel where an approver enters a JSON payload and chooses Resume with payload or Reject.
The same run detail is envisioned in the mobile app, where a push notification about a failed workflow opens the run and a single button retries the failing node. Runs sit downstream of the builder and its triggers, rely on stored connections when a credential needs renewing, and feed the analytics and AI diagnosis concepts that look across many runs at once.
What this concept shows
- Summary tiles for runs today, success rate, average duration and failed runs, each compared with the previous day
- Filters for status, workflow, trigger and date range, with a one-click reset
- A runs table with run IDs, trigger types, status pills for completed, running, failed and cancelled runs, start times and durations
- An execution timeline showing each node's status and timing alongside its input and output JSON
- A timestamped log stream tagged INFO, DEBUG, WARN or ERROR and attributed to the node that wrote each entry
- Typed error detail for a failed node, with Retry node, Resume run and Cancel run actions
- Runs that pause at a wait step for human input and resume with a JSON payload, or are rejected
- A mobile run detail opened from a push alert, with a Retry node button
How it works
- Open Runs from the side navigation to see the summary tiles and the table of recent executions.
- Narrow the list by status, workflow, trigger or date range to find the run in question.
- Open a run to follow its execution timeline, select a node, and read its input, output and logs.
- On a failed run, read the typed error and its context, then retry the failing node, resume the run or cancel it.
- On a paused run, enter the approval payload and resume the run, or reject the request.
- Away from the desk, tap a failure notification on a phone to open the run detail and retry the node.
Who it's for
- Operations and automation leads who own business-critical workflows
- Workflow builders debugging a new or changed automation
- On-call engineers responding to failed runs
- Managers and approvers who act on paused approval steps
Illustrations
5 illustrations of this concept. Select one to view it full size.
Runs List With Health Tiles and Filters
The illustration shows the Runs page inside the workspace shell, with Runs highlighted in the left navigation and a plan usage meter at the foot of the sidebar. Four tiles across the top summarize runs today, success rate, average duration and failed runs, each with a small change indicator against the previous day. Below them, a filter bar offers dropdowns for status, workflow and trigger, a date-range picker and a Reset filters button. The table lists sample workflows such as an order-to-cash flow, a lead router and a nightly database sync, each row with a monospaced run ID, a trigger type (webhook, schedule, API or chat), a status pill for completed, running, failed or cancelled, a relative start time sorted newest first, a duration and a row actions menu. The design demonstrates how a team can read run health at a glance and narrow a large volume of executions to the one that matters.
Completed Run With Timeline, Node Data and Logs
This view envisions the detail page of a successful run of a sample order-to-cash workflow, reached through a Back to Runs link. The header shows the workflow name, a Completed badge, a pinned version tag, the webhook trigger, the start time and the total duration, with a Re-run button and a disabled Cancel button on the right. Three panels follow. The execution timeline lists five nodes in order, from the webhook trigger through an order-amount condition, invoice creation and a receipt email to a write into a BigConsole datasink, each with a green check and its duration, and a footer confirming that all nodes completed. The middle panel shows the selected invoice node's input and output as formatted JSON with copy buttons. The logs panel streams timestamped INFO and DEBUG entries, each attributed to the node that wrote it, showing how a run can be audited step by step.
Failed Run With Typed Error and Recovery Actions
Here the design shows a failed run of a sample lead-routing workflow, reached through a breadcrumb from Runs. The header carries a Failed badge, the version, a schedule trigger, the start time and duration, plus a Run actions menu. The node timeline shows three completed steps, a fourth step that posts to a Slack channel outlined in red, and two downstream steps marked Skipped, with a View workflow graph button beneath. The Error detail panel labels the problem as a credential error, states that the Slack token expired with a 401 response, identifies the node, asks the user in plain language to reconnect the Slack connection and shows the error context as JSON. Retry node, Resume run and Cancel run buttons sit below it, with a note that retrying re-executes only that node. The logs panel highlights the error line and offers Download logs, a filter and an auto-scroll toggle.
Paused Run Awaiting an Approval Payload
This illustration shows run control for a sample purchase approval workflow whose amber header badge reads paused and awaiting input. The header gives the start time, notes that the run was triggered through the API and shows its run ID with a copy button, with Cancel run and Pause buttons at the top right. The node timeline shows an HTTP trigger, request validation, a purchase lookup and a risk-scoring step completed with timestamps and durations, then a wait node for manager approval highlighted as waiting for input, followed by pending steps that update a status, notify Slack and end the run. The central Resume run panel names the waiting node and provides a JSON payload editor, here holding an approval flag, with Resume with payload and Reject buttons and a note that the payload becomes the waiting node's input. A live logs panel ends with a warning that the run paused for approval.
Mobile Workflows List and Failed Run Alert
Two phones illustrate the mobile experience envisioned for FluidGrids. The left phone shows a Workflows screen under a workspace switcher, with search and filter icons and cards for sample workflows, each with an Active or Draft badge, its trigger, such as a new order or a daily schedule, and when it last ran. A floating add button and a bottom tab bar for Home, Workflows, Runs, Alerts and Me complete the screen. The right phone shows a push notification reporting that a lead-routing workflow failed, above the Run detail screen it opens. That screen lists the duration, start and finish times and node count, then expandable node rows: four completed steps and a final CRM step marked Failed, with a credential error explaining that the destination service's credentials are invalid or expired. A full-width Retry node button sits at the bottom, so recovery does not have to wait for a laptop.
Topics
- workflow run history
- workflow execution logs
- retry failed workflow node
- resume paused workflow
- human approval step in automation
- workflow run inspector
- node input and output inspection
- automation monitoring
- mobile workflow alerts
- workflow debugging
Related concepts
AI Failure Diagnosis and Repair
Ask why a run failed, review an AI-proposed fix as a versioned diff, and let triage group recurring failures into proposals.
3 illustrations
Analytics and Operational Health
Measure success rates, durations, error types and live worker health across every workflow in one place.
3 illustrations
Connections and Credentials
Authorize external services once, reuse them across every workflow, and keep the secrets out of the canvas.
2 illustrations
Triggers, Schedules and Webhooks
Decide what starts a workflow — a cron schedule, an incoming request, an API call or a chat message — and keep every trigger under control.
3 illustrations