Updated Nov 1, 2026

Execution Monitoring

What you'll learn

• How to access workflow execution history from the history (clock) icon
• How to read execution records and check success or failure status
• How the log level setting affects the company execution logs (Logs view)
• How to troubleshoot failed workflow executions

Execution monitoring lets you track every time a workflow runs and see whether it succeeded or failed. Use it to verify that your workflows are working and to diagnose issues when something goes wrong.

Accessing execution history

To view the execution history for your workflows:

1. Navigate to Automations > Workflows in the sidebar to open the workflows list page.
2. Click the history (clock) icon at the top of the list page.

This opens the execution history view, which shows a log of all past workflow executions. Each entry in the history includes when the workflow ran, which workflow it was, and whether the execution was successful.

What execution records show

Each execution record summarizes one run:

• Timestamp -- The date and time the workflow ran
• Workflow name -- Which workflow was executed
• Status -- one of eight values, grouped by lifecycle:
  • Accepted, not started yet: pending (an ingest-deferred hook run waiting to be claimed) and queued (an asynchronous run accepted through the /v1 API)
  • In flight: running, then dispatched once the run has been handed to the executor
  • Terminal: success, partial, error, or skipped (with a skipReason)
• Trigger metadata -- The trigger type, and for hook triggers the model and operation that fired it
• Outcome -- The ok flag plus the error or skipReason message when the run failed, finished partial, or was skipped

The record does not store each step's output; it captures the overall outcome of the run. When a step failed it also keeps a compact failedSteps roll-up (step index, error code and message), which the execution-history list does not display -- in the list, the error message is what names the failed steps. To see the outcome of each individual step -- per-step status, timestamps, and safeError -- open the plain Logs entry in the actions menu on the workflow's edit page (see below) or the debug panel; that detail lives in the company execution logs (log_entries), not in the execution-history record.

The partial status

partial means the engine finished the run but at least one step in it did not do its job. Two things count:

• An ordinary step failed. The engine records the failure and can continue with later steps. Fatal scope/authorization denials and exceeding the action-call cap stop the run and skip later steps.
• A step's condition could not be evaluated. The engine skips that step, so it never ran although nothing decided it should not. It counts as failed, with code condition_eval_error. A condition that evaluated to false is an ordinary skip and does not count.

The run then ends with ok: false, an error summary naming up to five failed steps by index (counting from 0) and code -- for example 1 of 2 steps failed: step 1 (contact_message_send_failed) -- and a failedSteps roll-up of {step, code, userMessage} entries. The execution history flags a partial row the same way as a failed one.

Steps you marked allow failure are still listed in failedSteps, with handled: true, but they do not make the run partial: a run whose only failures are handled ones stays success with ok: true. So a success record can carry failedSteps -- read ok, not whether the list is empty.

Every trigger records this verdict: hook runs (inline and ingest-deferred), temporal (scheduled) runs, manual Run runs, re-runs dispatched from the AutoTalk admin panel, and /v1 API runs in both modes -- a synchronous /v1 run stores partial on the record and returns it in the same 200 response, while an asynchronous run stores it for the poller to read. error is kept for a run that failed as a whole.

Only the execution record carries the verdict. The answer a manual run gives whoever started it is unchanged, so a parent workflow that runs this one through Execute workflow still reads workflow.step(N).data.ok as true when the child finished, even if the child's record says partial.

Runs started through the /v1 API carry more: logs (aggregated per-step lines, capped at 200 entries x 2000 characters) and, when the caller opts in, stepOutputs. Those fields are hidden from the execution-history list, but they come back in the API response for the run. failedSteps is not one of these extras: a /v1 run carries it only when a step failed, like a run from any other trigger, and on a clean run it is absent from the API response.

How log level affects the execution logs

Two different things are labelled Logs

The workflow's edit page offers both of them, in the same actions menu next to the page title -- so tell them apart by the icon, not by the page you are on:

• Logs with the list icon (also offered on each row of the workflows list) opens the execution history filtered to that workflow -- the same aggregate workflow_executions records the history (clock) icon shows, with no per-step breakdown.
• The plain Logs entry, which only the edit page has, opens the company execution logs (log_entries) filtered to that workflow -- these are the verbose, per-step rows.

Everything below about log level and per-step troubleshooting refers to the second one.

The Log Level setting on each workflow controls how much detail is written to the company's execution logs (log_entries) -- the verbose, per-step records you open from the plain Logs entry in the actions menu on the workflow's edit page. It does not change the execution-history records shown by the history (clock) icon: those carry only an aggregate status and are written the same way regardless of log level.

• Higher log levels write more detailed per-step information to the Logs view, including input values, output values, and intermediate data. This is very helpful during development and testing.
• Lower log levels write only essential information like success/failure status. This reduces noise and storage once a workflow is stable and running in production.

tip

Set the log level to a higher (more verbose) setting while you are building and testing a new workflow, then reduce it once the workflow is running reliably to keep the Logs view clean and manageable.

Troubleshooting failed executions

When a workflow execution fails, follow these steps to identify and fix the issue:

1. Open the execution history from the history (clock) icon on the workflows list page.
2. Find the failed execution in the list. A run that failed as a whole has status error; one that finished with a failed step, or with a step whose condition could not be evaluated, has status partial. Both are flagged as failures, and a partial row's error message names the failed steps and their codes.
3. Open the per-step logs to find which step failed. The execution-history record only shows the overall status and a single error message -- for a partial run that message names the failed step indexes and codes, but it has no per-step detail (inputs, outputs, timestamps). To pinpoint the failing step, open the workflow's edit page, open the actions menu beside the page title and choose the plain Logs entry (or use the debug panel): that view lists the per-step log_entries (status, timestamps, and executionContext.safeError) filtered to this workflow. The other Logs entry -- the one with the list icon, offered on the workflow row as well -- is a different view: it reopens the execution history you are already looking at.
4. Review the error details. Depending on the log level, the record may include error messages, the data that was passed to the step, and shared execution metadata such as executionContext.status, timestamps, and executionContext.safeError.
5. Fix the issue in the workflow. Common problems include:
   • CEL expressions in step fields that reference data which is not available (for example a contact field that is empty for this run)
   • A step condition that cannot be evaluated -- the step is skipped and the run ends partial with code condition_eval_error
   • Missing required fields in a step configuration
   • External services (webhooks) that are unavailable or returning errors
   • Invalid data formats passed between steps
6. Re-test the workflow after making your fix (the workflow must be enabled for on-demand runs). For manual and temporal workflows, use the Run button. For hook workflows, trigger the relevant event again. For temporal workflows you do not have to wait for the next scheduled run -- the same Run button works on demand -- though you can also wait for it or adjust the schedule.

Best practices for monitoring

• Check execution history regularly during the first few days after activating a new workflow. Early detection of issues prevents problems from compounding.
• Use the Start Debug button in the Steps section of the workflow form to test your workflow before activating it. Note that it runs each step for real (live HTTP calls, writes, and messages fire) -- it is not a dry run -- so point it at safe/test targets while debugging.
• Adjust log levels as needed. Increase verbosity when troubleshooting a specific issue, then reduce it once the problem is resolved.
• Review the workflows list periodically to ensure all enabled workflows are running as expected, using the filter and history tools on the list page.

Execution metadata shown in the UI is sanitized for safe debugging. It is intended to help you understand what failed without exposing raw stack traces, secrets, or provider payloads.

info

The history (clock) icon on the workflows list page shows executions across all workflows in one place. This makes it easy to spot patterns, such as a workflow that fails every time it runs, or one that has not executed in a long time.

Next steps

• Creating a workflow
• Trigger types
• Workflow inputs