Inngest Studio

A serverless workflow and event-driven function skill for building reliable background jobs, scheduled tasks, and multi-step workflows using Inngest's durable execution engine.

When to Use

Choose Inngest when:

• Building reliable background jobs that survive serverless function timeouts
• Creating multi-step workflows with automatic retries and error handling
• Implementing event-driven architectures with fan-out and orchestration
• Scheduling recurring tasks in serverless environments without cron infrastructure

Consider alternatives when:

• Simple one-shot tasks under 10 seconds — use standard serverless functions
• High-throughput event streaming — use Apache Kafka or AWS Kinesis
• Complex data pipelines — use Apache Airflow or Temporal

Quick Start

Copy
# Install Inngest
npm install inngest

# Start the Inngest dev server
npx inngest-cli@latest dev

Copy
import { Inngest } from 'inngest';

const inngest = new Inngest({ id: 'my-app' });

// Define a multi-step function
const processOrder = inngest.createFunction(
  { id: 'process-order', retries: 3 },
  { event: 'order/created' },
  async ({ event, step }) => {
    // Step 1: Validate inventory
    const inventory = await step.run('check-inventory', async () => {
      const items = event.data.items;
      return await checkInventoryLevels(items);
    });

    if (!inventory.available) {
      await step.run('notify-out-of-stock', async () => {
        await sendEmail(event.data.email, 'out-of-stock', {
          items: inventory.unavailable
        });
      });
      return { status: 'cancelled', reason: 'out_of_stock' };
    }

    // Step 2: Process payment
    const payment = await step.run('process-payment', async () => {
      return await chargeCard(event.data.paymentMethod, event.data.total);
    });

    // Step 3: Send confirmation (runs even if previous step was slow)
    await step.run('send-confirmation', async () => {
      await sendEmail(event.data.email, 'order-confirmed', {
        orderId: event.data.orderId,
        total: event.data.total
      });
    });

    // Step 4: Wait, then send follow-up
    await step.sleep('wait-for-delivery', '3 days');

    await step.run('send-review-request', async () => {
      await sendEmail(event.data.email, 'review-request', {
        orderId: event.data.orderId
      });
    });

    return { status: 'completed', paymentId: payment.id };
  }
);

// Scheduled function (cron)
const dailyReport = inngest.createFunction(
  { id: 'daily-report' },
  { cron: '0 9 * * *' },  // Every day at 9 AM
  async ({ step }) => {
    const metrics = await step.run('gather-metrics', async () => {
      return await getBusinessMetrics();
    });

    await step.run('send-report', async () => {
      await sendSlackMessage('#reports', formatReport(metrics));
    });
  }
);

Core Concepts

Inngest Execution Model

Concept	Description	Benefit
Durable Steps	Each step.run() is persisted	Survives function restarts
Automatic Retries	Failed steps retry with backoff	Handles transient errors
Event Triggers	Functions triggered by events	Decoupled architecture
Fan-out	One event triggers multiple functions	Parallel processing
Step Sleep	step.sleep() for delays	No idle compute cost
Concurrency Control	Limit parallel executions	Prevent overwhelming APIs

Event-Driven Architecture

Copy
// Send events from anywhere in your app
await inngest.send({
  name: 'user/signup.completed',
  data: {
    userId: 'user_123',
    email: '[email protected]',
    plan: 'free',
    referralCode: 'REF456'
  }
});

// Multiple functions react to the same event
const sendWelcomeEmail = inngest.createFunction(
  { id: 'send-welcome' },
  { event: 'user/signup.completed' },
  async ({ event, step }) => {
    await step.run('send-email', () =>
      sendEmail(event.data.email, 'welcome')
    );
  }
);

const setupDefaults = inngest.createFunction(
  { id: 'setup-defaults' },
  { event: 'user/signup.completed' },
  async ({ event, step }) => {
    await step.run('create-workspace', () =>
      createDefaultWorkspace(event.data.userId)
    );
    await step.run('create-project', () =>
      createSampleProject(event.data.userId)
    );
  }
);

const processReferral = inngest.createFunction(
  { id: 'process-referral' },
  { event: 'user/signup.completed' },
  async ({ event, step }) => {
    if (!event.data.referralCode) return;
    await step.run('credit-referrer', () =>
      creditReferrer(event.data.referralCode, event.data.userId)
    );
  }
);

Configuration

Option	Description	Default
id	Application identifier	Required
eventKey	Inngest event key for sending events	From env
signingKey	Webhook signing key for verification	From env
retries	Default retry count per function	3
concurrency	Maximum concurrent executions	Unlimited
batchEvents	Batch multiple events into one execution	false
rateLimit	Rate limit function executions	null
logLevel	Logging verbosity	"info"

Best Practices

1. Make each step idempotent because Inngest may retry failed steps, meaning the same step could execute multiple times; use idempotency keys to prevent duplicate side effects like double-charging or double-sending emails
2. Use step.sleep() instead of setTimeout for delays in workflows because step.sleep() is durable (does not consume compute during the wait), while setTimeout would require a continuously running function
3. Keep step functions focused and fast — each step.run() should do one thing; this gives Inngest fine-grained retry control and makes debugging easier since you can see exactly which step failed
4. Use concurrency limits when calling rate-limited external APIs to prevent overwhelming them during event bursts; configure concurrency: { limit: 5 } to cap parallel executions
5. Test functions locally using the Inngest dev server which provides a visual dashboard showing event flow, step execution, and retry behavior without deploying to production

Common Issues

Functions timing out in serverless environments: Serverless platforms have execution time limits (Vercel: 10s free, 60s pro). Inngest's step-based execution allows each step to be a separate function invocation, so break long workflows into multiple short steps that each complete within the timeout.

Event ordering not guaranteed: Events sent close together may be processed out of order. Design functions to be order-independent, use step.waitForEvent to synchronize when ordering matters, and include timestamps in events for proper sequencing logic within functions.

Duplicate event processing: Network retries and at-least-once delivery can cause duplicate events. Include a unique id field in events for deduplication, and make all step handlers idempotent so processing the same event twice produces the same result without unwanted side effects.