Inngest pricing: when should I move from Hobby to Pro based on executions and concurrency?

Most teams hit Inngest’s Hobby limits the same way I used to hit queue limits on Lambda: everything is fine in dev, fine in early production, and then one “good problem”—more traffic, a new AI workflow, a noisy tenant—suddenly makes concurrency and executions very real.

This guide walks through when it’s time to move from Hobby to Pro based on executions and concurrency, and how to think about that upgrade in terms of reliability, not just price.

---

How Inngest pricing maps to executions and concurrency

Inngest pricing is built around two things:

• Executions – how many times your functions run (end-to-end workflows, background jobs, scheduled tasks, durable endpoints).
• Concurrency & flow control – how many runs execute in parallel and how much control you have over noisy-neighbor behavior (per-tenant queues, rate limiting, throttling, priorities).

You’re on Hobby when:

• You’re validating fit: a few workflows, limited traffic, mostly internal users.
• You’re okay with simpler flow control and lower overall volume.
• You don’t need strict guarantees around per-tenant isolation yet.

You should be eyeing Pro when:

• You’re running production traffic and can’t afford partial failures.
• You’re hitting or approaching execution caps on Hobby.
• You need multi-tenant concurrency control so one customer doesn’t impact everyone else.

I’ll break this down by usage pattern so you can map your own numbers.

---

When executions push you from Hobby to Pro

Think of executions as: “How many times a month do we expect Inngest to run a function from first step to last step?”

Each of these counts as at least one execution:

• A webhook handler that fans out into multi-step processing
• A nightly sync job with 5–6 step.run() calls
• An AI agent workflow that chains tools and model calls
• A durable API endpoint that resumes after timeouts or retries

Rule-of-thumb thresholds

You’re comfortable on Hobby if:

• Total executions are low to mid-5 figures/month.
• Spikes are small and predictable (internal tools, admin operations).
• Most workflows are single-tenant or low-cardinality.

You should plan to move to Pro when:

1. Execution volume is part of core product behavior

   • User signups, content creation, critical data syncs funnel through Inngest.
   • If Inngest throttled or rejected runs, users would feel it.

2. You’re approaching Hobby’s monthly execution ceiling

   • You see sustained growth in traces week over week.
   • Even if you’re not at the cap yet, your trend line says “we’ll hit this soon.”

3. You’re starting to parallelize work

   • You split jobs into smaller steps and fan out across tenants.
   • You’re using step.run() heavily to make failures safe and debuggable.
   • Each fan-out branch is its own execution; scale multiplies quickly.

From a reliability POV: moving to Pro before you’re at the ceiling protects you from “sudden success” outages—launch days, marketing pushes, or a big customer migrating data.

---

When concurrency & flow control make Pro the obvious choice

Executions are about how much work you do. Concurrency is about how safely you do it at scale, especially in multi-tenant systems.

On Hobby, you can run concurrent work, but you’ll eventually feel constraints around:

• Noisy neighbors – one high-volume customer running thousands of jobs.
• Backpressure – queue-like behavior during spikes, with limited control.
• Shared concurrency – all tenants effectively share the same “lane.”

On Pro, you unlock flow control primitives that treat concurrency as a product feature, not an infrastructure project:

• Multi-tenant concurrency keys – isolate each customer or space:

  export const syncSpace = inngest.createFunction(
    { id: "sync-space", concurrency: { key: "event.data.spaceId", limit: 1 } },
    { event: "space/sync.requested" },
    async ({ event, step }) => {
      // Only one sync per space at a time
      await step.run("sync-data", async () => { /* ... */ });
    }
  );
  

• Per-key limits – “one sync per space,” “two imports per org,” etc.
• Throttling and prioritization – smooth load without rewriting logic.

Clear concurrency-driven triggers to upgrade

You should move from Hobby to Pro when:

1. You have real multi-tenant behavior

   • SaaS with “spaces, projects, orgs, teams” as tenants.
   • You need each tenant to feel like they have their own queue.
   • You want GitBook-style isolation: one space’s syncs never block another.

2. You’re seeing noisy-neighbor incidents

   • One tenant kicks off bulk imports or API-heavy workflows.
   • Other customers start seeing slowdowns or delays.
   • On Pro, you fix this with concurrency keys instead of new infra.

3. You need strict per-tenant ordering

   • “Only run one sync at a time per space/org.”
   • “Don’t start the next job for this customer until the previous one finishes.”
   • GitBook used Inngest’s concurrency management to ensure:

     “As soon as the previous sync has ended, the next ones for this specific space will run immediately and won’t be affected by any other user or customer.”

4. You’re migrating off custom queues/workers

   • You’re replacing hand-rolled workers, SQS, cron stacks.
   • You want the same (or better) control without maintaining that stack.
   • Pro lets you express queue semantics directly in code instead of infra YAML.

If you can describe a production incident using phrases like “one big customer flooded the queue,” “other tenants got stuck behind long jobs,” or “we had to build per-tenant queues by hand,” you’re in Pro territory.

---

Execution + concurrency: how they interact in real systems

In practice, you don’t upgrade for just executions or just concurrency; you upgrade because both are growing together.

Here’s how that usually looks:

Phase 1: Prototype and early launch (Hobby is fine)

• A handful of inngest.createFunction() definitions.
• Primarily internal or beta users.
• You’re figuring out how to structure Steps, retries, and checkpointing.
• Execution volume is low; concurrency issues are rare.

You’re using this time to:

• Get comfortable with step.run('name', async () => ...).
• Use Traces to understand how your workflows actually run.
• Avoid building custom workers/queues at all.

Phase 2: “We’re live” and volume grows (start planning Pro)

• Workflows become part of the core product path.
• Executions scale with revenue events: signups, syncs, AI operations.
• You see spikes (launches, imports, backfills) that drive concurrency.

At this point:

• You don’t want executives asking, “Why are new signups stuck?” because a backfill job is clogging the same pipe.
• You want to guarantee that each tenant has a fair, isolated lane.
• You want to use flow control instead of throttling everything globally.

This is when moving to Pro early is a strategic choice:

• You stay well below the risk threshold for execution caps.
• You gain concurrency keys and flow control before the first big incident.
• You can promise “your syncs don’t get slower as we add more customers.”

Phase 3: Multi-tenant at scale (Pro is mandatory)

• You’re running many thousands to millions of executions per month.
• You have diverse workloads: webhooks, agents, scheduled tasks, durable endpoints.
• Multi-tenant fairness and SLAs matter.

Here, Pro is baseline—not for vanity metrics, but to keep multi-tenant behavior predictable:

• Each tenant gets effectively their own queue semantics.
• You smooth load with throttling and prioritization instead of reactive fire drills.
• If something fails, you use Replay and Bulk Cancellation instead of log-grepping.

---

A practical checklist: are you ready to move to Pro?

If you answer “yes” to most of these, it’s time to talk about Pro:

Execution-driven signals

• Inngest functions now sit on critical paths (signups, billing, core data).
• You see steady execution growth and expect launches or migrations.
• You’re planning:
  • New AI workflows (multi-step, tool-heavy agents).
  • Bi-directional syncs or ETL-style data movement.
  • More scheduled tasks replacing cron.

Concurrency-driven signals

• You run a multi-tenant SaaS (spaces, projects, orgs, workspaces).
• You need per-tenant ordering (“one sync at a time per space/org”).
• You’ve experienced:
  • One customer delaying everyone else’s jobs.
  • Time spent tweaking workers/queues just to keep up.
• You want built-in flow control instead of rolling:
  • Per-tenant queues
  • Rate limiting logic
  • Manual throttling scripts

If those checkboxes describe your world, the math usually works out: Pro is cheaper than the time you’ll spend debugging noisy neighbors or rebuilding queue semantics by hand.

---

How to think beyond price: DX and operations on Pro

The real value of moving to Pro is not just “more executions.” It’s that you get to run higher-stakes workloads without paying an infrastructure tax.

You keep using the same primitives:

export const processOrder = inngest.createFunction(
  { id: "process-order" },
  { event: "order/created" },
  async ({ event, step }) => {
    const order = await step.run("load-order", async () => { /* ... */ });
    await step.run("charge", async () => { /* ... */ });
    await step.run("notify", async () => { /* ... */ });
  }
);

But behind the scenes, on Pro:

• Each step.run() is a durable transaction:
  • Retries automatically on failure.
  • Runs once on success.
  • Resumes from the last successful Step instead of starting over.
• Flow control ensures:
  • No single tenant can monopolize concurrency.
  • Backpressure is expressed in config, not a new infra project.
• Traces plus step-level data let you:
  • Inspect inputs/outputs.
  • Query, cancel, or replay runs at scale.
  • Operate production without building custom admin tools.

That’s the shift: workflows, agents, endpoints, background jobs—however it’s written, wherever it runs—become unbreakable without wrangling workers, queues, and cron.

---

Bottom line: when to move from Hobby to Pro

Summing it up in one decision framework:

• Stay on Hobby while:

  • Executions are modest and not on product-critical paths.
  • You’re not yet multi-tenant at scale.
  • You’re still shaping your workflow model.

• Move to Pro when:

  • Inngest is on the critical path for revenue or user experience.
  • Execution volume is rising and tied to product growth.
  • You need multi-tenant concurrency keys, per-tenant ordering, and flow control to keep noisy neighbors from impacting everyone else.

If you’re already thinking about per-tenant queues, rate limiting, or backpressure, you’re past the “Hobby” stage—even if you haven’t hit the hard caps yet. That’s when Pro stops being a pricing tier and starts being your reliability boundary.

---

Next Step

Get Started(https://www.inngest.com/contact?ref=homepage-hero)