Retry

Many things can go wrong in a serverless environment. If your API does not respond with a success status code (2XX), we retry the request to ensure every message will be delivered.

The maximum number of retries depends on your current plan. By default, we retry the maximum amount of times, but you can set it lower by sending the Upstash-Retries header:

The backoff algorithm calculates the retry delay based on the number of retries. Each delay is capped at 1 day.

n = how many times this request has been retried
delay =  min(86400, e ** (2.5*n)) // in seconds

​

Retry-After Header

Instead of using the default backoff algorithm, you can specify when QStash should retry your message. To do this, include the Retry-After header in your response to QStash request. You can set this header to a value in seconds or in the RFC1123 date format.

Note that you can only delay retries up to the maximum value of the default backoff algorithm, which is one day. If you specify a value beyond this limit, the backoff algorithm will be applied.

This feature is particularly useful if your application has rate limits, ensuring retries are scheduled appropriately without wasting attempts during restricted periods.

Retry-After: 0                             // Next retry will be scheduled immediately without any delay.
Retry-After: 10                            // Next retry will be scheduled after a 10-second delay.
Retry-After: Sun, 27 Jun 2024 12:16:24 GMT // Next retry will be scheduled for the specified date, within the allowable limits.

​

Upstash-Retried Header

QStash adds the Upstash-Retried header to requests sent to your API. This indicates how many times the request has been retried.

Upstash-Retried: 0 // This is the first attempt
Upstash-Retried: 1 // This request has been sent once before and now is the second attempt
Upstash-Retried: 2 // This request has been sent twice before and now is the third attempt