QStash will abort a delivery attempt if the HTTP call to your endpoint does not return within the plan-specific Max HTTP Response Duration.
See the current limits on the QStash pricing page.
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: 
curl -XPOST \
    -H 'Authorization: Bearer XXX' \
    -H "Content-type: application/json" \
    -H "Upstash-Retries: 2" \
    -d '{ "hello": "world" }' \
    'https://qstash.upstash.io/v2/publish/https://my-api...'
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
ndelay
112s
22m28s
330m8ss
46h7m6s
524h
624h

​
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. 
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: 6m5s                          // Next retry will be scheduled after 6 minutes 5 seconds 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

​
Non-Retryable Error

By default, QStash retries requests for any response that does not return a successful 2XX status code. To explicitly disable retries for a given message, respond with a 489 status code and include the header Upstash-NonRetryable-Error: true. When this header is present, QStash will immediately mark the message as failed and skip any further retry attempts. The message will then be forwarded to the Dead Letter Queue (DLQ) for manual review and resolution. This mechanism is particularly useful in scenarios where retries are generally enabled but should be bypassed for specific known errors—such as invalid payloads or non-recoverable conditions.