Retry
For free: Requests will be considered failed if not processed within 15 minutes.
For pay-as-you-go: Requests will be considered failed if not processed within 2 hours.
For fixed pricing: Requests will be considered failed if not processed within Custom(you may timeout as much as needed).
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 | delay |
---|---|
1 | 12s |
2 | 2m28s |
3 | 30m8ss |
4 | 6h7m6s |
5 | 24h |
6 | 24h |
Retry-After Headers
Instead of using the default backoff algorithm, you can specify when QStash should retry your message. To do this, include one of the following headers in your response to QStash request.
- Retry-After
- X-RateLimit-Reset
- X-RateLimit-Reset-Requests
- X-RateLimit-Reset-Tokens
These headers can be set to a value in seconds, the RFC1123 date format, or a duration format (e.g., 6m5s). For the duration format, valid time units are “ns”, “us” (or “µs”), “ms”, “s”, “m”, “h”.
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.
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.
Was this page helpful?