English Vocabulary for Inngest Background Jobs

Inngest is a serverless workflow and background job platform that lets you write reliable, multi-step functions in TypeScript or Python without managing queues, workers, or infrastructure. It is designed for the serverless era — your functions run as individual steps that can sleep, wait for events, and retry automatically, all without holding a long-running server process. If your team uses Inngest to handle background processing, scheduled tasks, or complex workflows, understanding its vocabulary will help you design better functions, debug failures, and communicate clearly in architecture reviews. This post covers the essential Inngest terms.

Key Vocabulary

createFunction The core Inngest API for defining a background function. You call inngest.createFunction() with a configuration object (including the function ID and trigger) and a handler function. The handler receives event and step objects as arguments and defines the function’s logic. Example: “Create an Inngest function with createFunction to handle post-purchase processing — pass in the trigger event name and write the steps for sending confirmation email, updating inventory, and notifying the warehouse.”

Trigger (event / cron) The condition that causes an Inngest function to execute. An event trigger fires when a specific named event is sent to Inngest. A cron trigger fires on a schedule defined by a cron expression. One function can have one trigger. Example: “Use an event trigger on user.signup for the onboarding workflow and a cron trigger with 0 8 * * 1 for the Monday morning digest email — each trigger type serves different use cases.”

step.run A method that wraps a unit of work inside an Inngest step. Steps are automatically retried on failure and their results are memoized — if the function is retried (due to a crash or timeout), completed steps are not re-executed. This makes multi-step functions safe to re-run. Example: “Wrap each external API call in step.run so that if the function fails after calling Stripe but before sending the confirmation email, the Stripe charge is not made again on retry.”

step.sleep A method that pauses an Inngest function for a specified duration — seconds, minutes, hours, or days — without consuming any compute resources during the pause. The function resumes exactly where it left off when the sleep period ends. Example: “Use step.sleep('3 days') to pause the trial reminder workflow — the function will resume automatically three days after the trial starts and send the reminder email without any cron job or scheduled task.”

Concurrency key A configuration option that limits how many instances of a function run simultaneously for a given key value. For example, setting a concurrency key of event.data.user_id ensures that only one instance of the function runs per user at a time, preventing race conditions. Example: “Add a concurrency key on event.data.account_id for the billing sync function — we don’t want two sync jobs running for the same account simultaneously or we’ll get duplicate charges.”

Cancellation The ability to stop a running or sleeping Inngest function based on an event. You configure a cancel-on event in the function definition, and when that event is sent, Inngest automatically cancels any matching running function instances. Useful for aborting workflows when a user’s state changes. Example: “Configure cancellation on user.deleted for the onboarding sequence — if a user deletes their account while the sequence is running, we don’t want to keep sending them emails.”

Event payload The data object sent with an Inngest event. It contains a name (the event type string) and a data object with arbitrary fields. The payload is available in the function handler as event.data and is also used for matching in concurrency keys and cancellation rules. Example: “Make sure the order.placed event payload includes the order_id, user_id, and total_amount fields — the fulfillment function needs all three to process the order correctly.”

How to Use This Vocabulary

Inngest architecture discussions typically focus on step design — “how do we break this workflow into discrete, retriable steps?” — and trigger selection — “should this be event-driven or scheduled?” The key insight to communicate is that step.run boundaries define both retry units and checkpoints: if the function crashes, Inngest replays from the last completed step rather than from the beginning.

Concurrency and cancellation discussions come up when teams integrate Inngest with user-facing actions. “What happens if the user triggers this function twice quickly?” leads to a concurrency key discussion. “What if the user cancels their subscription mid-workflow?” leads to a cancellation configuration discussion.

Example Conversation

Sasha: The order processing function is failing halfway through — Stripe charges are going through but the fulfillment API call is failing. We’re also seeing duplicate charges on retry. Lee: Are the steps wrapped in step.run? If the Stripe call isn’t in a step, it will re-execute on every retry. Sasha: It’s not. I’ll wrap both calls in separate step.run blocks — that way Stripe only charges once even if the fulfillment step fails and retries. Lee: Also add a concurrency key on order_id so we can’t process the same order twice in parallel.

Practice

1. Design an Inngest function for a user onboarding sequence: send a welcome email immediately, wait 3 days, send a tips email, wait 7 days, send an upgrade offer. Write out each step in English, naming the Inngest methods you would use.
2. Explain to a teammate why wrapping code in step.run matters for reliability. Use the words “retry,” “memoized,” “idempotent,” and “checkpoint” in your explanation.
3. Give an example of a workflow where you would use both a concurrency key and a cancellation rule. Describe the business scenario, why each is needed, and what would go wrong without them.