.svg?fit=max&auto=format&n=mBaWmVpTOpDBIB6_&q=85&s=36c7989ebe591de9ac7d3618f0a04a28)
.svg?fit=max&auto=format&n=mBaWmVpTOpDBIB6_&q=85&s=5afe473ba3ef2469d3e839045bcb099c)
One event, one run per automation
An event is matched against every active automation for the app. Each match queues its own run, so three automations watching installs produce three runs from one install, each with its own record, its own retries, and its own outcome. Runs appear in two places: the Recent runs modal inside each automation’s editor, filterable by date range, trigger event, and status, and the Recent runs page under Automations, which lists every run across all automations of the app. The automations list keeps the aggregate numbers: runs over the selected range, success rate with a failure count, and median and p95 run time.Recent runs across the app
Open Automations > Runs in the sidebar (or View all runs on the automations list) for one table of every run in the app, newest first. Each row names its automation, the store, the trigger, the status and, for a failed, blocked or skipped run, the reason. Filter by status, automation, store domain or trigger event; the table pages through history twenty runs at a time. A run paused on a Wait is listed as soon as it starts, with the time it will resume and the kind of Wait it is paused on, so a drip that is mid-sequence is never invisible. Refresh to see waiting rows resume and running rows finish.Statuses
Waiting and running rows are excluded from success-rate metrics until they finish.
Retries
A run gets three attempts, backing off 10 seconds, then 60, then 180. The run row carries how many retries it used, so a success on the third attempt is visible as one. Not everything is retried. A permanent failure (a send step with no recipient at all, no email content saved, a Slack workspace no longer connected or a Slack channel that was deleted, an unknown action, two Waits in parallel in a flow saved before that was refused at activation) fails immediately, because retrying it would produce the same result three times over. Transient failures (a delivery hiccup, a timeout, a Slack rate limit) are what the backoff is for. Completed actions in a drip are remembered on the run, so a retry or resume does not send the same email twice.Why a step didn’t do anything
Common outcomes that aren’t failures:- The store uninstalled. Send steps are skipped for a store that has uninstalled, on every trigger except Uninstalled itself. Sends addressed to specific people still go out.
- No named contact matched. A send addressed to a store’s contacts falls back to the store’s own email rather than skipping the store.
- The value didn’t change. A Populate custom field step that writes the value already stored changes nothing, and doesn’t fire Custom field changes.
- A chain hit the cap. Automation-caused custom-field writes stop after three hops. See Custom field changes.