Retry Mechanism for Failed Data Transfers (Public Preview)
- 05 Jun 2025
- 1 Minute to read
- PDF
Retry Mechanism for Failed Data Transfers (Public Preview)
- Updated on 05 Jun 2025
- 1 Minute to read
- PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback!
Bobsled’s system includes a smart retry mechanism to handle failed data transfers efficiently. This ensures minimal disruption and cost while providing flexibility for varying transfer schedules.
FEATURE IN PUBLIC PREVIEW
It is suitable for certain production workloads but may not be appropriate for all use cases. For guidance, contact your account representative.
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:
If a job remains unresolved after all retries, users can manually review and address the issue, or pause the transfer until corrections are made.
Was this article helpful?