Skip to main content
Every time a workflow runs, it creates an execution record. Use executions to monitor what’s happening and troubleshoot issues.

​
History range

The execution history view has a range selector to control how far back you can see runs. On other plans the 30-day option is shown but locked behind an upgrade prompt. Existing execution records older than your range are not deleted. They just aren’t surfaced in the dropdown selection.

​
Needs-review digest

The needs-review digest email counts failed runs that nobody has reviewed yet, over a time window. Its Open executions button opens Workflows > History and lists exactly those runs.
  • The heading names the window, for example Failed runs not yet reviewed since …, and shows the total. It matches the number in the email.
  • Show all dates drops the window and lists every failed run not yet reviewed.
  • Back to all history returns to the normal run list.
The search box and range picker are hidden while this list is showing. If the date in the link is broken, the page says The date in this link is not valid and shows no list.

​
Deleting a workflow

Deleting a workflow cancels its runs that are still in progress, so no more steps run for them.

​
Auto-pause and failure emails

A workflow that fails 5 times in a row switches itself off. Runs in progress stop, and admins get one email saying the workflow was auto-paused. Fix the problem, then switch the workflow back on. Some failures say nothing about the workflow, so they don’t count toward the 5 or reset the count:
  • The account can’t send right now: out of credits, a trial that hasn’t converted, or a spending cap.
  • This contact can’t be reached: DND, restricted, deleted, or no phone or email.
  • A problem on Nedzo’s side: an outage, a network error, or a timeout.
A workflow that is still on but fails often sends a high failure rate email. It goes out at most once a day per workflow. Test runs and the failures above don’t count, and a workflow that is already off sends none. When Nedzo knows what an error means, both emails explain it in plain words above the raw error text.

​
Execution statuses

The Status column in Workflows > History shows what each run is doing. A Waiting run can show one of these reasons: A Queued run is about to start, or it is waiting behind the concurrency cap. The UI shows the same status for both.

​
Stuck runs

A run shows Stuck once it is past the point where Nedzo would move it on its own:
  • Queued for more than 4 hours
  • Running with no progress for 4 hours
  • Waiting more than 4 hours past its resume time, or 25 hours for a follow-up call
If a waiting run is more than 4 hours past its resume time and nothing is set to resume it, Nedzo marks it Failed so it doesn’t stay stuck. When runs in the list look stuck, a red banner at the top of History shows how many. It counts only the runs in the range and search you picked, so every run it counts is in the list below it. Runs from deleted workflows are not counted. Contact support with the run ID.

​
Concurrency limits

Nedzo caps how many executions run at the same time. Support can raise both caps. It is not self-serve, so email support with the number you need and why.

​
What happens when you hit the cap

Enroll a large batch and the runs past the cap sit in Queued instead of failing. They wait up to 3 hours and start as soon as a slot frees up. Before this change they failed after about 14 seconds. An execution still queued after 3 hours fails. The error names the cap it waited on, so you know whether to split the batch or ask for a higher limit.

​
What’s tracked

Each execution records:
  • Trigger type and data — What started the workflow and the data it carried
  • Current position — Which node is executing (or waiting)
  • Step outputs — The result of each completed step
  • Error details — What went wrong if a step failed
  • Timestamps — When it started, completed, or failed

​
Step outputs

Every action stores its output after running. These outputs are available to later steps as variables. For example, a voice call step stores:
  • Call ID
  • Status and outcome
  • Extracted data fields
  • Recording URL
A webhook step stores:
  • HTTP status code
  • Response body

​
Testing

Individual steps can be tested from within their configuration panel. Step-level testing lets you verify each action works correctly before publishing. Test executions are flagged separately and don’t count against limits.

​
Troubleshooting

​
Workflow didn’t trigger

  • Check that the workflow is published and the activate/deactivate toggle is set to active
  • Verify the trigger conditions match the event
  • Check deduplication — the same trigger for the same contact within the dedup window (default 1 minute) is ignored

​
Step failed

  • Check the error message in the execution details
  • Common causes: missing integration connection, invalid phone/email, expired OAuth token
  • Transient failures (network issues, rate limits) are retried automatically up to 3 times. Time spent waiting on the concurrency cap is not a failure and does not spend a retry.

​
Retry a failed run

Open a failed run and click Retry Execution. The run picks up at the step that failed. Steps that finished before it do not run again, and their outputs are kept. The failed step runs again, so some runs can’t be retried:
  • A step that may already have sent its message or call. That is a step that timed out, failed after it started sending, or placed a call that got no answer back.
  • A webhook that got a 5xx, 408 or 429 answer, or no answer in time. A webhook your endpoint refused with another 4xx can be retried, and it is sent again.
You can also retry over the API. See Retry a run.

​
Follow-up call could not be scheduled

When a Voice call step is due a follow-up call and Nedzo can’t schedule it, the run shows Failed. It does not show Completed. The call step reads “Follow-up call N of M could not be scheduled” and gives the reason. The run stops on that step, so no later step runs for a contact whose follow-ups were lost. It counts as a failed run, like any other step failure.

​
Workflow stuck on “Waiting”

The run is paused until a set time. Check the reason and time under Waiting in the Status column. The run picks up again at that time. If the time has long passed, the run shows Stuck instead. See Stuck runs.