Skip to main content

Retries & Backoffs

Learn the Q-flow Subscription Retries and Exponential backoffs

Configure Subscription Retries and Exponential backoffs​

Q-Flow will wait 30 seconds for a response after delivering a message. After 30 seconds, if the endpoint hasn’t responded, the message is queued for a retry. Q-Flow uses an exponential backoff retry policy for event delivery to increase successful deliveries without human intervention. You can configure the maximum retry attempts within the endpoint set-up. For example, if you configure the retry attempts to the maximum, it will attempt multiple times over a 24-hour period.

To configure the maximum retries for the Subscription:

Configure retry

  1. Within your Subscription, navigate to the Set a Webhook Endpoint section.
  2. Use the slider to choose the maximum retries for the Subcription (minmum of 1, maximum of 10).
  3. Press the Create or Update the Subscription.

That's it! You've successfully configured your endpoint with a maximum number of retry attempts. We'll handle retries using the exponential backoff rules outlined below. And don’t worry—if, for any reason, the events cannot be delivered within the retry period, we’ll move them to dead letter storage, giving you the flexibility to replay them at a convenient time.

Exponential backoff retry policy​

Q-Flow uses an exponential backoff retry policy for event delivery to increase successful deliveries without human intervention.

Exponential Back off period

  • 10 seconds
  • 30 seconds
  • 1 minute
  • 5 minutes
  • 10 minutes
  • 30 minutes
  • 1 hour
  • 3 hours
  • 6 hours
  • Every 12 hours up to 24 hours

Example Scenario for Long and Short retries periods​

ScenarioExample
When Long Retries HelpNon-Time-Sensitive Systems: If your analytics pipeline can tolerate a delay, you’ll still want the data eventually, even if it’s 12/24 hours late. Configuring max retries over a 24-hour period ensures you don’t lose key insights.
When Short Retries Are BetterTime-Sensitive Journeys: For a real-time user engagement or “warm journey,” receiving an event 12/18 hours late is worse than not receiving it at all. In this case, configure fewer or shorter retries so you aren’t sending stale data.