> ## Documentation Index
> Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Runs and troubleshooting

Every time an event matches an active automation, Meridian records a **run**: which trigger fired it, which store it was for, whether it succeeded, and why not if it didn't.

## 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](/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

| Status | What it means |
| - | - |
| **Running** | Queued or actively executing a segment |
| **Waiting** | Paused on a [Wait](/wait) step until its resume time (or until-event timeout) |
| **Success** | The flow finished every reachable step after any waits |
| **Failed** | A step failed and the run stopped. The failure reason is recorded on the run |
| **Blocked** | The app was already at its monthly automation allowance, so the flow never executed. Terminal, never retried |
| **Cancelled** | A Wait exit event fired for the store, or an until-event Wait timed out with cancel |
| **Skipped** | The automation was paused or deleted, or a Send email step references an inactive email. The run stops and records the reason, including after a Wait |

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](/deleted) 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](/populate-custom-field) step that writes the value already stored changes nothing, and doesn't fire [Custom field changes](/custom-field-changed).
* **A chain hit the cap.** Automation-caused custom-field writes stop after three hops. See [Custom field changes](/custom-field-changed).

## Waits and partial progress

A [Wait](/wait) deliberately leaves a run mid-flow. Actions before the Wait may already have sent; actions after it run only after resume. Conditions after a Wait re-check live store data. Without a Wait, a run still either completes its reachable side effects or fails before leaving partial sends from a crashed job (completed node tracking).

## Before it's live

To see all of this without sending anything, [test the flow](/automation-test-runs) first: same walk, same condition semantics, every step traced (including Wait resume times).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.