# Retrying a Failed Run

When a Bolt run fails, you don't need to manually rebuild commands or kick off a new schedule from scratch. From the **Run Details** page, retry the failed run with a single click and pick how much you want to re-execute.

* **Retry from failure** *(default)* — resume from the failed command. The first failed `dbt` command is substituted with `dbt retry` so only the failed models are re-executed.
* **Retry all** — re-run **every** original command verbatim, regardless of which ones succeeded or failed.

In both modes, a **new Bolt run is created**. The original run is **never modified** — its status, logs, and artifacts stay intact for auditing.

<div data-with-frame="true"><figure><img src="/files/641DmwgZn81aaL00T6Ox" alt=""><figcaption></figcaption></figure></div>

#### Two retry modes

| Mode                   | What re-runs                                                                                        | When to use it                                                                                                                                |
| ---------------------- | --------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **Retry from failure** | Only the failed commands. The first failing `dbt` command becomes `dbt retry` (failed models only). | The common case — transient warehouse errors, a flaky test, a single broken model. Cheapest and fastest path back to green.                   |
| **Retry all**          | Every original command, in order, exactly as the schedule defined them.                             | The fix changed an upstream model or invalidated earlier results, so you need a clean rebuild. Or you want to verify the full schedule again. |

{% hint style="info" %}
**Infrastructure commands are skipped** in both modes — `git clone`, `dbt deps`, and other setup steps always run automatically on every Bolt run, so you don't need to (and can't) retry them.
{% endhint %}

***

#### Retrying from the UI

1. Open the failed run from the Run History of any schedule.
2. On the **Run Details** page, click the **Retry** action.
3. Pick a retry mode:
   * **Retry from failure** *(default)*
   * **Retry all commands**
4. Confirm. A new Bolt run is queued immediately and a link to it appears in the confirmation toast.
5. Track the new run in the same Run History — it appears with its own run ID and links back to the original via the **Retried from** indicator.

{% @arcade/embed flowId="50vvelsozFOANXp474wi" url="<https://app.arcade.software/share/50vvelsozFOANXp474wi>" %}

#### What happens to the original run

* The original run's status (`failed`), logs, artifacts, and timeline are **unchanged**.
* The new run is a **separate** entry in the Run History — it has its own run ID, start time, and logs.
* If you retry the same original run more than once, each retry creates its own new run. Retries do not chain — they all reference the original failed run as their parent.
* Notifications (Slack / email / MS Teams) configured on the schedule fire on the **new** run as if it were any other Bolt run.

***

#### Triggering retries from code

The same retry behaviour is available from the Paradime CLI, the Python SDK, and the GraphQL API — useful if you want to automate retries from CI, an external orchestrator, or an incident-response tool.

| Path                                                                 | Reference                                                                   |
| -------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| [**CLI**](/app-help/developers/paradime-cli/bolt-cli.md)             | `paradime bolt retry` / `paradime bolt schedule retry`                      |
| [**SDK**](/app-help/developers/python-sdk/modules/bolt.md)           | `paradime.bolt.retry_run` / `retry_run_all` / `retry_schedule_from_failure` |
| [**GraphQL**](/app-help/developers/graphql-api/examples/bolt-api.md) | `retryBoltRun` / `retryAllBoltRun` / `retryBoltRunFromFailure`              |

***

#### Related

* [Viewing Run Log History](/app-help/products/bolt/managing-schedules/viewing-run-log-history.md) — Find the failed run you want to retry
* [Analyzing Individual Run Details](/app-help/products/bolt/managing-schedules/analyzing-run-details.md) — Diagnose the failure before retrying


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.paradime.io/app-help/products/bolt/managing-schedules/retrying-a-failed-run.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.