Make Cloudflare Workflows retry around rate limits instead of fixed timers

Cloudflare added dynamic retry delays to Workflows on July 9, 2026. Instead of picking only a fixed delay plus constant, linear, or exponential backoff, a Workflow step can now pass a function to retries.delay and calculate the next wait from the current attempt and the thrown error.

Use this when a workflow calls APIs with different failure modes: wait longer on rate-limit errors, retry faster after a short network failure, or map provider guidance such as Retry-After into your next delay. This is a practical fit for customer sync jobs, AI-provider orchestration, payment/CRM integrations, and any durable workflow that should avoid both blind hammering and unnecessary waiting.

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();
  },
);

Check before using

• Confirm your Workflow code is using the current Cloudflare Workflows API and docs.
• Treat error-message matching as a fallback; prefer structured error data when your SDK exposes it.
• Add a maximum retry count and clear terminal-error path so bad credentials or malformed payloads do not loop.
• Test against one intentionally rate-limited API call before relying on it for paid providers.

Sources

• Cloudflare changelog: dynamic retry delay support for Workflows.
• Cloudflare Workflows docs: sleeping, retrying, and the retries.delay function shape.