---
title: "Retrying runs"
description: "Resume a failed run from the step that failed, on the code deployed now."
---

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

# Retrying runs

A run that failed can be retried with [RetryRun](/workflows-api/RetryRun/) or an SDK client
(`client.retry(runId)` in TypeScript, `c.Retry(ctx, runID)` in Go, `client.retry(run_id)` in
Python), until its data is deleted 30 days after it ended. Fix the cause first, for example by
deploying a fix or restoring the system a step calls.

A retry resumes the run; it doesn't start a new one:

- **The run is `running` again,** with the same ID and its `attempt` increased by one.
- **Completed steps keep their results** and don't run again.
- **The step that failed** (the run's `causeStepId`) gets a fresh set of retry attempts. Attempt
  numbers keep counting up, so [idempotency keys](/workflows/retries#idempotency) are never reused.
- **Waiting child workflows are re-examined:** a child that has since ended delivers its outcome,
  a failed or cancelled child is retried the same way, and a child whose data was already deleted
  is started again.
- **The run continues on the code deployed now.**
- **The run gets its full time limit again.**

The answer is the run. Retrying a run that isn't `failed` is `409 run_not_failed`.

Only failed runs can be retried. A cancelled or timed-out run can't, and a completed run is
final: start a new run instead.

Source: https://docs.ezghcloud.com/workflows/retrying-runs/index.mdx