Inngest alternatives and where the step retry sits

Your Inngest function loads an invoice, then charges the card. The charge succeeds. The step crashes before Inngest stores the result. The retry charges the card again. The load step does not run again. The boundary was the step, not the payment.

This post shows where Inngest's retry boundary sits, and what still has to be idempotent on the provider.

Where Inngest draws the retry line

step.run makes one operation durable. Inngest saves a completed step's result. A later retry continues without repeating that step. Each step.run has its own retry counter. The retry guide says the default is four retries after the initial attempt, so five tries. retries: 0 turns retries off. The count is per step, not a shared pool across the function.

Code outside a step runs again when the function resumes. Best practices say to put API calls and database writes inside step.run, and to keep pure math outside. A side effect outside a step repeats on every resume.

The same docs say a request can succeed and then fail before Inngest records the result. The retry sends it again. A saved step result cannot undo that duplicate. You pass an idempotency key the provider understands, derived from the business id, not from the attempt number.

What the October 2026 price counts

The pricing page lists Free at $0 with 50,000 executions, 5 concurrent steps, and 24-hour trace history. Pro starts at $99 a month with 1 million executions and 7-day traces. Business starts at $499 a month with 10 million executions and 14-day traces. The calculator note says executions are runs times steps plus one. A function with two steps is not one execution.

That meter is the orchestration. It is not the provider's bill, and it is not a guarantee the provider saw one charge.

What the step boundary does not cover

Inngest will not rerun a step it has already saved. It will rerun a step it never saved, even if the provider already did the work. That is the hole. Fill it with the provider key, or with your own record of success, checked before you call again.

If the provider does not store idempotency keys, neither Inngest nor a retry wrapper can make that write exactly once. Say so in the design. Do not hide it behind a step name.

Swytchcode sits on the call inside the step. You enable one method. A policy can block a second shape of that call, such as an amount over a cap, before it is sent. POST and PATCH are retried by Swytchcode only when an idempotency key is set. On the October 2026 pricing page, Free includes allow and deny for 100 live commands. Durable execution platforms is the page to read if you are still choosing the orchestrator. Policy as code is the rule on the call the step makes.

A billing function makes the boundary obvious. load-invoice reads your database and can be repeated. charge-card calls the provider and must not be repeated without a key. email-receipt is a third side effect with its own retry counter. If you put the charge and the email in one step, a failed email retries the charge. Inngest will reuse the step only after it saved a result. Split them. Give the charge a key of order-123-charge, not attempt-2. Give the email order-123-receipt. If the provider has no idempotency support, write a row in your database before you call, and skip the call when the row exists. That row is your key. The step engine will not invent one. Name the step after the side effect, not after the whole function, or the retry boundary is wider than the risk. If the email fails four times, the charge step stays saved and only the receipt is retried.

Name the step, then name the key

Follow this step to install the CLI. Use one of these.

npm install -g swytchcode

irm https://cli.swytchcode.com/install.ps1 | iex

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Confirm the install, then start the project.

swy --version
swy init

Search the registry, copy the ID from the local list, and add that ID. Inside step.run, pass one idempotency value tied to the invoice or order.

swy search <provider>
swy get <name from search>
swy list methods
swy add <canonical_id from swy list methods>

Connect the provider. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. Validate the policy for the cap.

swy auth connect <provider>
swy policy validate

Keep the resume logic in Inngest. Put the provider key on the step that spends money, and do not derive that key from the attempt count. A saved charge step should stay saved when a later receipt step fails and retries on its own counter. The invoice id is the key. The attempt number is not. Split the charge and the receipt if they can fail separately.

Related reading

• Durable execution platforms. Step engines compared, including where they stop.
• Policy as code. The cap applies on the retry as well as the first try.
• Log every API call an agent makes. Step traces and provider responses answer different questions.
• Human approval. A retried step should not skip a hold.

FAQ

Does one Inngest function retry restart every step?

No. Each step.run has its own counter. A saved step returns its result. The failed step is the one that retries. Code you left outside any step runs again on resume.

How many times does a step run by default?

Once, plus up to four retries, unless you set retries. That is five attempts. retries: 0 disables retries. TypeScript SDK v4 allows 0 to 20.

Does a step result make the provider call exactly once?

No. Inngest's docs say the provider call can succeed and the result can be lost before it is saved. The retry sends the call again. Use the provider's idempotency key, stable across attempts.

Is an execution the same as a function run?

The pricing calculator says executions equal runs times steps plus one. Two steps are more than one execution. Check that before you compare the $99 Pro plan with a per-call runtime.