Monitor workflow runs

Every time a workflow fires — automatically or by hand — Nash keeps a record of it. Execution History is where you go to see that record: every run, what it touched, and what happened at each step.

Workflows is a beta feature; if you don't have it yet, reach out to Nash for early access.

Open Execution History

Open a saved workflow in the workflow editor. At the top right, a toggle switches between Editor and Runs — select Runs to open Execution History, which lists every run of that workflow, most recent first. Each row shows when it ran, what it touched, how long it took, and its status. Select Editor to go back to building.

The Runs side of the toggle also shows the latest run's status and how long ago it ran (or No runs yet), so you can tell whether the workflow has fired recently without opening anything.

Execution History starts with the Last 7 days; switch to Last 30 days or Last 90 days to look further back. Use the All, Success, Failed, and Running tabs to narrow the list by outcome — each tab shows how many runs it holds.

Check run health at a glance

Above the canvas, a strip of four numbers sums up how the workflow is doing today, so you can spot a problem without opening Execution History:

• Runs today — how many times the workflow has run today.
• Success rate — the share of today's finished runs that ended in Success rather than Failed.
• Errored — how many of today's runs failed. When it's above zero, View in Runs opens Execution History filtered to those failed runs.
• Avg run time — how long today's successful runs took on average.

A number shows — until there's something to measure. To hide the strip, select the eye icon at its top right; Show headline metrics brings it back. Hiding it only changes your own view — your teammates still see it.

Run statuses

Each run's row in Execution History carries one status for the run as a whole:

• Success — the run finished. That includes a run whose conditions weren't met: the workflow correctly decided this particular job didn't qualify and stopped.
• Failed — a step hit an error that stopped the run.
• Running — still in progress.
• Paused — waiting before it continues (for example, ahead of a delayed action) — it picks back up on its own.
• Pending or Queued — waiting to start.
• Cancelled — stopped before it finished.

Open a run and each step has its own status. Steps share Running, Paused, and Failed with the run, and add a few of their own:

• Completed — the step did its work.
• Passed — the step's conditions were met, so the workflow continued.
• Filtered — the conditions weren't met, so the workflow stopped there. This isn't a failure — it's the workflow correctly deciding this particular job didn't qualify, so nothing downstream should happen — unless you've set up a separate path for that case (a Yes/No branch), in which case it continues down that path instead.
• Ready — queued to go.

Run detail

Open any run to see:

• Entities — the orders, jobs, or deliveries the run touched, each linked so you can jump straight to it.
• Execution Steps — every step the run went through, in order, each with its own status.

Together these let you confirm a workflow did what you expected, or see exactly where it didn't.

Test vs Run

The workflow editor gives you two ways to try a workflow before you rely on it:

• Test runs it in dry-run mode — nothing it would normally do (send a notification, apply a strategy, and so on) actually happens. Testing a single step also offers an optional live-test toggle for cases like a message action, so you can send one real, clearly test-labeled message to confirm an integration works.
• Run is not a simulation — it executes the workflow end-to-end and fires any action it reaches. Use it once you're ready to see a workflow work for real, or to catch up orders it missed. See run a workflow manually for more.

Still building the workflow itself? See build a workflow.