New Guide: Running Background Jobs with Prisma ORM + TypeScript
Join our Discord
Sign up for free

Retries and failures

It's inevitable that steps in a function fail. In many cases - but not always - it's useful to automatically retry the step that errors. Inngest has this capability built in and, unlike other systems, errors can be customized based off of logic within the steps itself.

Failure detection

Steps are classified as failed if either of the following conditions are met:

  • A step exits with a non-zero status code, as per unix defaults
  • A step returns a non-2xx status code within their response

Retry policies

By default, each step is retried 3 times using exponential backoff with jitter. Retries can be customized using the status or statusCode response:

  • 2xx - Successful: this is not a failure, no retry is necessary
  • 4xx - Bad request: this step will not be retried, as this error is irrecovarble
  • 5xx - Server error: something temporarily failed. This will be retried according to the retry policy (3 times, by default).

We're currently working on implementing custom retry policies per steps, documented in this issue.