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

# Runs

> Launching, monitoring, and managing individual executions of a journey

A **run** is a single execution of a journey against a specific list of recipients. You manage runs from the **Runs** tab on a journey. This is where you upload your contacts, start or schedule a run, and watch it play out.

## The Runs Tab

The Runs tab has two panels:

* **Left panel** — the list of every run for this journey, with status, recipient count, and create/schedule time
* **Right panel** — the selected run's recipients, with their current status and progress through the flow

At the top of the tab there's a **New Run** button to create a run, and an **Export** button to download results.

## Creating and Starting a Run

A run always starts as a **draft**. A draft run exists but hasn't begun processing yet — it's the staging area where you load recipients.

The flow is:

1. Click **New Run** and give the run a name.
2. Use **Import** to upload a CSV of recipients into the draft. The CSV must include a `phone_number` column; every other column maps to a [journey data field](/journeys/journey-data).
3. Review the imported recipients in the right panel.
4. Either click **Start Run** to begin immediately, or click **Schedule** to pick a date, time, and timezone for the run to begin on its own.

You can delete a draft run at any time before it starts.

## Run Statuses

As a run moves through its lifecycle, it passes through these statuses:

| Status        | Meaning                                                           |
| ------------- | ----------------------------------------------------------------- |
| **pending**   | Draft run. Recipients can still be imported. Not yet launched.    |
| **queued**    | Scheduled to start at a future time.                              |
| **running**   | Actively processing recipients.                                   |
| **paused**    | Temporarily stopped. Recipients hold their place. Can be resumed. |
| **completed** | Every recipient has reached the end of their path.                |
| **failed**    | The run hit a terminal error.                                     |
| **cancelled** | Stopped manually. Remaining recipients won't be processed.        |

You can pause, resume, or cancel a run from the run's controls.

## Recipients

Each recipient in a run has their own status reflecting where they are in the journey — pending, in progress, completed, failed, and so on. The right panel shows each recipient's phone number, current status, which node they're on, and the next time they're scheduled to do something.

Different recipients in the same run can be at different nodes at the same time. Some might be mid-call, others parked on a delay, others already finished — that's the journey executing recipient-by-recipient.

## Scheduling

When you schedule a run instead of starting it immediately, you pick:

* The **date and time** the run should begin
* The **timezone** that date and time are in

The run sits in the queued state until that moment, then flips to running automatically. You can reschedule or cancel a queued run at any time before it fires.

## Pausing and Resuming

Pausing a run freezes everyone in place. No new calls or messages are sent, and no delays tick down while the run is paused. Recipients that were mid-action (on an active call, for example) complete that action, but they won't advance to the next node until the run is resumed.

Resuming a run picks up exactly where it left off.

## Exporting Results

When a run has generated enough activity to review, use the **Export** button at the top of the Runs tab to download the results as a CSV. Exports let you bring the data into your own reporting or operations tools.

## Multiple Runs on One Journey

Nothing stops you from having several runs active at the same time on the same journey. A typical pattern:

* A **daytime run** launched in the morning for one batch of recipients
* A **follow-up run** launched later in the week for recipients from the first run that didn't answer
* A **test run** with a handful of internal numbers to validate changes to the flow

Each run has its own recipients and its own status, so you can manage them independently.