Skip to main content
Updated Aug 4, 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 -- running, success, error, or skipped
  • 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 or was skipped

The record does not store the result of each individual step; it captures the overall outcome of the run. To see the outcome of each individual step -- per-step status, timestamps, and safeError -- open the workflow's Logs view (see below) or the debug panel; that detail lives in the company execution logs (log_entries), not in the execution-history record.

How log level affects the execution logs​

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 workflow's Logs button. 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. Failed runs are marked with an error status.
  3. Open the Logs view to find which step failed. The execution-history record only shows the overall status and a single error message -- it has no per-step breakdown. To pinpoint the failing step, open the workflow's Logs view (or the debug panel), which lists the per-step log_entries (status, timestamps, and executionContext.safeError) for the run.
  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)
    • 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​

Last updated on
On this page