---
title: "Retry Mechanism for Failed Data Transfers (Public Preview)"
slug: "retry-mechanism-for-failed-data-transfers-public-preview"
updated: 2025-06-12T08:49:50Z
published: 2025-06-12T08:49:50Z
canonical: "bobsled.com/retry-mechanism-for-failed-data-transfers-public-preview"
---

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

# Retry Mechanism for Failed Data Transfers (Public Preview)

Bobsled’s system includes a smart retry mechanism to handle failed [data transfers](/v2/docs/transferring-data) efficiently. This ensures minimal disruption and cost while providing flexibility for varying transfer [schedules](/v2/docs/sync-preferences-and-transfer-scheduling).

---

### Key Features

| **Targeted retries** | Only tables that failed with new data are retried. Successful transfers continue unaffected. |
| --- | --- |
| **Exponential back-off** | Retries follow an intelligent schedule, starting with short intervals and progressively increasing based on the transfer’s delivery frequency. |
| **Reduced alerts** | Repeated failures of the same table won’t trigger duplicate notifications, minimizing noise. |
| **User control** | If immediate action is needed, users can initiate a retry by clicking “Sync Now.” |
| **Transparent status tracking** | Failed jobs are marked, and retry statuses are displayed. |

Retry schedule examples:

- **Frequent transfers (e.g., every 5 minutes):** Retries occur during the next scheduled transfer.
- **Less frequent transfers (e.g., monthly):** Retries use a Fibonacci-based schedule to maximize recovery within the delivery window.

---

### Benefits

| **Efficiency** | Prevents redundant retries, saving resources and costs. |
| --- | --- |
| **Timely recovery** | Ensures failed tables are retried within appropriate timeframes, balancing urgency and efficiency. |
| **Improved user experience** | Minimizes unnecessary alerts and allows users to focus on resolving the root cause of failures. |

> [!NOTE]
> **NOTE:** If a job remains unresolved after all retries, users can manually review and address the issue, or pause the transfer until corrections are made.