With Workflows, you can configure built-in retry behavior for each step. Previously, you could configure step retries with fixed delay durations, such as seconds, minutes, or hours, and backoff strategies such as constant, linear, or exponential.
Step retries now support dynamic delay functions. Instead of choosing only a base delay and backoff strategy, pass a function to retries.delay and calculate the next delay from the failed attempt and thrown error.
This is useful when retries should depend on the failure. Your Workflow may need to wait longer after a rate-limit error, but retry sooner after a short network failure. The delay function can also accommodate provider guidance if, for example, a downstream API returns a Retry-After value in its error messaging.
JavaScript
await step.do("sync customer",{retries: {limit: 5,delay: ({ ctx, error }) => {if (error.message.includes("rate limit")) {return `${ctx.attempt * 30} seconds`;}return "10 seconds";},},},async () => {await syncCustomer();},);TypeScript
await step.do("sync customer",{retries: {limit: 5,delay: ({ ctx, error }) => {if (error.message.includes("rate limit")) {return `${ctx.attempt * 30} seconds`;}return "10 seconds";},},},async () => {await syncCustomer();},);
Dynamic delay functions can return a duration string, a number, or a promise that resolves to a duration. Use them to add adaptive retry behavior without writing separate queue or scheduling logic. For more information, refer to Sleeping and retrying.
Source: Cloudflare
Latest Posts
- OAuth support for the AWS MCP Server

- AWS Config now supports 191 additional managed rules

- Amazon SageMaker HyperPod now supports deep health checks for Slurm clusters with continuous provisioning

- Amazon MSK Replicator now supports replication from external Apache Kafka clusters to MSK Standard brokers






