Inngest is a serverless event-driven workflow orchestration platform. It lets you build durable, stateful background jobs and workflows without managing infrastructure. Use this skill when working with Inngest functions, events, schemas, testing, or anything else Inngest-related.
Comprehensive best practices and guidelines for creating, refactoring, and maintaining Inngest code - maintained by Theo Ai.
Use this skill when working with Inngest functions and anything Inngest related. This includes, but is not limited to:
Core Inngest concepts:
Why use it: You write business logic as "step functions" and Inngest handles reliability, retries, and orchestration. Great for long-running processes, AI workflows, and background jobs that need to survive failures.
stepstep.run() call.step as a separete, self-fulfilling,
serverless-like function.step. The step object must never be nested.step as argument to function calls. Keep the use of
step constrained within the Inngest function.step are serialized and deserialized by
Inngest's infrastructure. This means that complex objects and
functions cannot be returned by a call to step.step.fetch() is better than calls to fetch
directly; a busy-wait loop can probably leverage
step.waitForEvent(), step.sleept(), step.sleepUntil(),
step.delay(), etc depending on the scenariostep.run() over
step.invoke() when possible, as the former allows fanout
operations to be aggregated and visualized under the same function
call in the Inngest WebUI, improving traceability. However, consider
step.invoke() when you specifically need independent concurrency
control, as inline step.run() calls cannot have their own
concurrency limits separate from the parent function.Promise.all resolution.Zod
infrastructure in place.NonRetriableErrorlogger and not console.log