Automation Health and Troubleshooting

Use Automation Health to see which automations ran for a submission and to diagnose failures.

PRO Last reviewed

Automation Health records what happened each time automations ran for a submission: which automations matched, which actions ran, how long they took, and what failed. Use it when an automation did not do what you expected and you need to find out where it stopped.

Automations are available in Elzo Forms PRO.

Open the history

Go to Forms → Settings → Automations and open the Health & History tab. The form and settings automation screens also link to it directly, filtered to the automations shown there.

The screen has two lists:

  • Automations — one row per automation, with its current status, last run, last issue, and success and failure counts. Use this to find an automation that is failing repeatedly.
  • Recent runs — one row per submission that triggered automations. Use this to investigate a specific submission.

Filters are available for form, status, automation, source, and date range.

Read a run

Open a run to see its details. The header shows the run status, start time, duration, and source. Below it are two tables:

  • Automation records — each automation that was considered, its origin (global or form-level), its status, and its safe code.
  • Action records — each action that ran, its status, duration, safe code, and a recommendation for fixing the problem.

A run’s status is one of running, success, warning, failed, stopped, or abandoned. A stopped run ended because an automation or action deliberately halted processing, which is not necessarily a fault.

Copy diagnostic summary puts the run’s safe codes and counts on the clipboard, which is the fastest way to include useful detail in a support request.

What is and is not recorded

Execution history stores statuses, error codes, and timing information. It does not store form field values, email content, webhook payloads, or secrets. A run record tells you that an action failed and why, not what data it carried.

History is enabled by default and kept for 30 days. Both settings are on the General tab under Automation execution history, where the retention period can be set to 7, 14, 30, or 90 days. Old records are removed daily by WordPress cron, and Run cleanup now removes them immediately.

Warning: Clear filtered history permanently deletes the execution history matching the current filters. Forms and automations are not affected, but the deleted records cannot be recovered.

Automation Logs on a submission

Each submission also has an Automation Logs panel showing the detailed execution trace for that one submission. This is separate from Automation Health and is off by default, so the panel is normally empty. Enabling it requires setting the elzo_forms_pro_automation_logs_enabled option; there is no screen for it in the admin. Automation Health is the supported way to review runs.

Test an automation instead of waiting for a visitor

Rather than submitting a form repeatedly to reproduce a problem, use the automation’s own test runner.

  1. Open the automation and click Test.
  2. Select a form and an existing submission to test against.
  3. Click Run test.

The test simulates side effects: no email is sent, no cookie is set, and the submission is not modified. Only the selected automation runs, so references to results produced by other automations are unavailable. Cookies, query parameters, and the request body are simulated as empty, since the original request no longer exists.

Enable Send real webhook requests to have each reached Webhook action contact its real endpoint. Everything else stays simulated.

Troubleshooting

The automation never ran

Check: confirm Elzo Forms PRO is active and the automation is enabled. Look for the submission under Recent runs. If no run exists at all, the automations were never reached — a submission flagged as spam is skipped entirely. If a run exists but the automation is recorded with the Conditions not met code, its conditions did not match this submission.

Expected behavior: every non-spam submission of a form with at least one enabled automation produces a run record.

Later automations were skipped

Check: an earlier automation may have Stop other automations if this automation matches selected, or one of its actions may use the Stop all automations error behavior. Global Automations run before a form’s own automations, so a global rule can stop form-level ones. The run status will be stopped.

Expected behavior: without a stop instruction, every matching automation runs.

An action failed

Check: open the run and read the action’s safe code and recommendation. Frequent codes include:

Code Meaning
Webhook request failed The endpoint could not be reached or did not respond in time.
Webhook returned an unexpected status The endpoint responded outside the configured success status range.
Unsafe webhook URL The address was blocked before the request was sent. Local and private network addresses are not allowed.
Invalid email recipient A recipient address was not valid, often because a referenced value was empty.
Future action reference An action referenced output from an action that runs after it. Move the source action earlier.
Reference not found A referenced workflow path could not be resolved for this submission.
Action unavailable The action’s provider is not installed or active.
Runtime deadline exceeded The workflow ran longer than the 30-second runtime budget.

Expected behavior: a successful action is recorded with a success status and no safe code.

An action’s result is uncertain

Check: a run may report that an action may have completed its side effect but the final result could not be confirmed. This is not retried automatically. Verify the outcome in the receiving system before running the automation again, so you do not create a duplicate record.

Expected behavior: confirmed actions record a definite success or failure.

Emails are not arriving

Check: if the run records the Send email action as successful, WordPress accepted the message and the problem is in mail delivery rather than in the automation. Configure SMTP or a transactional email service. If the action failed with Invalid email recipient, the address itself is the problem.

Expected behavior: a successful Send email action means WordPress accepted the email for sending. It is not a delivery confirmation.

The run details are incomplete

Check: long workflows can hit logging limits, recorded as Execution history truncated or Trace truncated. These are warnings about recording, not about execution. The workflow itself was not stopped by them.

Expected behavior: the run summary remains accurate even when detailed action rows are truncated.

Next steps