Inngest vs Upstash QStash for cron + retries: what breaks when you need multi-step state and resume?

Most teams start with “just cron and retries” and only feel the pain later—when a simple scheduled call turns into a multi-step workflow that has to track state, avoid double-processing, and resume in the middle after a failure.

That’s the fault line between Upstash QStash and Inngest.

QStash is great when all you need is “call this URL on a schedule with retries.” As soon as you add multi-step logic, tenant isolation, or the need to replay individual steps, you’re effectively building a workflow engine on top of QStash—workers, queues, idempotency, dead-letter queues, and all. Inngest bakes those concerns into code-level primitives like step.run() and flow control, so the workflow itself becomes the execution plan.

Below is how I’d choose between them, having spent years keeping Lambda workers, SQS queues, and DLQs from falling over every time a multi-tenant job went sideways.

Quick Answer: The best overall choice for multi-step cron jobs with stateful retries and mid-flow resume is Inngest. If your priority is simple, stateless HTTP cron with minimal setup, Upstash QStash is often a stronger fit. For teams that want to keep HTTP cron but are starting to add multi-step fan-out/fan-in flows, consider pairing QStash with custom workers—but understand you’re effectively rebuilding what Inngest already gives you.

---

At-a-Glance Comparison

Rank	Option	Best For	Primary Strength	Watch Out For
1	Inngest	Multi-step workflows, AI agents, and background jobs that must resume mid-flow	Code-level durability with step.run() and automatic checkpointing	Overkill for single-shot callbacks or trivial cron
2	Upstash QStash	Simple cron + retries hitting HTTP endpoints	Low-friction HTTP cron and retry for serverless APIs	No built-in step semantics, state, or per-step observability
3	QStash + Custom Workers	Teams intent on DIY workflow infra on top of HTTP cron	Full control over queues, workers, and state model	You own everything: idempotency, DLQs, replays, flow control, observability

---

Comparison Criteria

We evaluated each option against how real systems break once you leave the “hello world cron” phase:

• Multi-step state & resume: Can you express a workflow as named steps, checkpoint progress automatically, and resume from the last successful step instead of starting over?
• Retries, idempotency & flow control: Does the platform give you automatic retries, idempotent execution, and multi-tenant safety (concurrency keys, throttling, prioritization) without bespoke infrastructure?
• Observability & recovery: When something fails, can you see exactly which step broke with its inputs/outputs, then query, cancel, or replay runs without building an internal admin tool?

---

Detailed Breakdown

1. Inngest (Best overall for multi-step, stateful cron + retries)

Inngest ranks as the top choice because it treats durability as a code-level concern: every step.run() is a transaction with automatic retries and checkpointing, so multi-step cron jobs and background workflows can resume from the last successful step instead of re-running everything.

What it does well:

• Code-level durability & resume:

  • You write workflows as functions using inngest.createFunction() and break them into named Steps with step.run('name', async () => ...).
  • On failure (timeouts, network errors, transient downstream issues), Inngest automatically retries the failed step, not the entire function.
  • Progress is checkpointed between steps, so a 10-step job that fails on step 7 will resume at step 7 once the issue is resolved—no partial state reconstruction, no “start from scratch and hope it’s idempotent.”
  • This is exactly the failure mode that burned my own teams: multi-step webhooks and sync jobs that half-applied changes and left us stitching logs to figure out what ran.

  import { inngest } from "@/inngest/client";
  
  export const nightlySync = inngest.createFunction(
    { id: "nightly-sync" },
    { cron: "0 2 * * *" }, // 2am UTC
    async ({ step, event }) => {
      const users = await step.run("load-users", async () => {
        return fetchUsersToSync();
      });
  
      const updated = await step.run("sync-external", async () => {
        return syncWithExternalAPI(users);
      });
  
      await step.run("persist-results", async () => {
        return saveSyncResult(updated);
      });
    }
  );
  

• Infraless, multi-environment execution:

  • No workers, queues, or pollers to manage. You connect your app once, and Inngest orchestrates the rest.

  • Runs anywhere: edge, serverless, or traditional environments.

  • Triggered by API calls, webhooks, or schedules (cron), using the same programming model.

  • You get one-command local setup via the dev server:

    npx --ignore-scripts=false inngest-cli dev
    

  • Local runs behave like production—including retries and checkpointing—so you can debug the real workflow, not an approximation.

• Flow control for multi-tenant workloads:

  • Concurrency keys and throttling let you isolate tenants and prevent noisy neighbors without hand-rolled queue topologies.
  • For example, GitBook uses Inngest to give each “space” its own queue, so one tenant’s heavy sync can’t delay another’s.
  • You can configure per-tenant concurrency and rate limits at the function level instead of building custom rate-limiters around QStash or your workers.

• Observable by default (Traces, structured logs, replay):

  • Every run has instant Traces with step-level inputs/outputs, structured logs, and real-time execution details.
  • You can query, cancel, or replay runs in bulk—no bespoke admin dashboard.
  • For AI and agent-style workflows, Traces include every prompt/response pair, so you can debug model calls alongside other steps.
  • When you need to fix a bad deployment or backfill, Replay and Bulk Cancellation let you act on thousands of runs at once.

• Enterprise-ready reliability & scale:

  • Trusted in production at Replit, SoundCloud, Cohere, TripAdvisor, Resend, and GitBook.
  • SOC 2 Type II, E2E encryption middleware, SSO & SAML, HIPAA BAA availability.
  • Handles 100K+ executions per second with low-latency execution.

Tradeoffs & Limitations:

• Overkill for trivial, stateless cron:
  • If all you need is “hit this URL every 5 minutes and retry once,” Inngest’s step semantics and Traces may feel like more than you need.
  • You’re adopting a workflow model (functions + steps) rather than “fire a URL”; that’s a feature when you have multi-step logic, but it’s another concept to learn for very simple cases.

Decision Trigger: Choose Inngest if you want multi-step cron jobs and background workflows that must be reliable, multi-tenant safe, and debuggable—where each step is named, retriable, and checkpointed, and you care about being able to query, cancel, or replay runs without building infrastructure around it.

---

2. Upstash QStash (Best for simple cron + retries over HTTP)

Upstash QStash is the strongest fit when your needs look like “call this endpoint on a schedule with retries” and nothing more: no mid-flow state, no multi-step orchestration, no per-step observability.

What it does well:

• Minimal-friction HTTP cron:

  • Define a schedule; QStash will send an HTTP request to your endpoint on that cadence.
  • Great for simple tasks like:
    • Triggering a cache warmup.
    • Kicking off a nightly report job.
    • Pinging an internal API that does the work.

• Basic retries & dead-lettering:

  • QStash will retry failed requests based on its configuration (e.g., backoff + max attempts).
  • You get reliability at the “request to endpoint” boundary without rolling your own poller.

• Serverless-friendly delivery:

  • Designed to work well with serverless platforms: you expose an endpoint; QStash hits it.
  • This works nicely when each scheduled job is a single HTTP invocation that can be retried safely as a whole.

Tradeoffs & Limitations:

• No first-class step semantics:

  • QStash knows about HTTP messages, not workflow steps.
  • If your cron job involves multiple steps (fetch, transform, fan-out, write), QStash can only retry the entire HTTP invocation.
  • If step 3 fails after step 1–2 have side effects, you either:
    • Rebuild idempotency across all steps yourself, or
    • Accept partial state and manual cleanup.

• No automatic mid-flow resume:

  • There’s no concept of “resume from step 3 after failure”; QStash just re-hits your endpoint.
  • To implement resume, you must:
    • Persist which step has run for which tenant/job.
    • Branch your code on that saved state.
    • Carefully implement idempotent updates for each step.
  • That’s essentially the workflow engine problem Inngest is designed to solve with step.run() and checkpointing.

• Limited observability at the workflow level:

  • QStash can tell you which HTTP calls failed and retried, but it doesn’t know about the steps inside your handler.
  • You still end up:
    • Searching logs across your app and QStash.
    • Adding ad-hoc trace IDs and log fields to correlate runs.
    • Building your own UI or scripts for mass replays or cancellations.
  • Contrast that with Inngest’s Traces, where each step’s inputs/outputs are visible and replayable.

• No multi-tenant flow control primitives:

  • You can approximate per-tenant queues and rate limits by:
    • Creating separate schedules or endpoints per tenant.
    • Adding your own concurrency control in the app or DB.
  • But QStash doesn’t give you built-in concurrency keys, throttling, or prioritization at the workflow level.

Decision Trigger: Choose Upstash QStash if you want simple, stateless cron + retries that call HTTP endpoints, your jobs are single-step or fully idempotent, and you’re comfortable owning multi-step state, observability, and recovery behavior inside your application.

---

3. QStash + Custom Workers (Best for teams determined to DIY workflow infra)

QStash + custom workers stands out for teams who want QStash’s HTTP cron surface but are willing to build the workflow engine themselves: queues, workers, idempotency, multi-step state, and replay.

What it does well:

• Full control over architecture & semantics:

  • You can design exactly how multi-step state is stored (e.g., in Postgres, Redis, DynamoDB).
  • You decide how to model steps, retries, and resume semantics.
  • QStash acts as a scheduler / trigger for workers, which can then push messages into SQS, Kafka, or your own queues.

• Separation of concerns (in theory):

  • QStash handles “when to run.”
  • Your workers and queues handle “what to do” and “how to orchestrate steps.”
  • This can work well if you already have a mature worker system and just need a cron trigger.

Tradeoffs & Limitations:

• You’re rebuilding the queue stack:

  • To match what Inngest gives out-of-the-box, you’d need to implement or maintain:
    • Workers (Lambda, containers, or pods).
    • Queues and topics (SQS, Kafka, Redis, etc.).
    • Step modeling and state persistence.
    • Automatic retries per step.
    • Idempotency and at-least-once delivery semantics.
    • Concurrency control and rate limiting per tenant.
    • Dead-letter queues and recovery tooling.
    • Observability (traces, structured logs, step-level views).
    • Replays (per-step and bulk).
  • I’ve lived this stack. It works, but it’s a tax you pay before you ship product features.

• Custom observability and admin UIs:

  • You’ll need to build:
    • A way to inspect runs (dashboards, log aggregation).
    • Tools to cancel stuck jobs and replay failed ones.
    • Run correlation (e.g., tracing across services).
  • Inngest’s Traces, Replay, and Bulk Cancellation exist specifically to avoid this internal tooling treadmill.

• Harder to keep behavior consistent across environments:

  • Local vs production behavior can drift:
    • Different queues.
    • Different worker counts.
    • Different retry and timeout characteristics.
  • Inngest’s dev server (inngest-cli dev) is designed so local workflows behave like production, including retries and checkpointing.

Decision Trigger: Choose QStash + custom workers only if you already have (or are committed to building) a mature job/queue infrastructure and you want QStash purely as a scheduler. If you’re starting from scratch and know you need multi-step state and resume, Inngest will get you there faster and with far less operational overhead.

---

What Actually Breaks When You Need Multi-Step State and Resume?

Using QStash as your starting point, here’s where cracks typically appear as workflows grow:

1. Partial state after failures

   • Workflow: cron triggers an HTTP endpoint that:
     1. Fetches a batch of users.
     2. Calls an external API per user.
     3. Writes results to your DB.
   • If the process dies halfway through step 2:
     • Some users are synced, others aren’t.
     • QStash retries the entire endpoint: you now have to ensure every write, every external call, and every side-effect is perfectly idempotent.
   • With Inngest:
     • Steps are explicit (load-users, sync-external, persist-results).
     • If sync-external fails, only that step is retried; load-users won’t run again unless you replay from that step.

2. No concept of “current step” or “resume point”

   • You end up storing ad-hoc state in a DB:
     • status: "step_2_in_progress", last_successful_step: "step_1".
   • Every time your endpoint runs, it branches logic based on that state.
   • Testing and debugging become painful because flow is conditional and scattered.
   • With Inngest:
     • The workflow code is the execution plan; steps are linear and named.
     • Checkpointing is automatic; resuming from the right step is a platform behavior, not a pattern you re-implement.

3. Unbounded retries and noisy neighbors

   • QStash retries failed endpoints without knowledge of tenant boundaries.
   • A single noisy tenant or failing job can:
     • Flood your workers.
     • Starve other tenants.
   • You start adding:
     • Per-tenant queues.
     • Separate schedules.
     • Custom rate limiters.
   • Inngest gives you flow control primitives:
     • Concurrency keys: “only N runs per tenant at a time.”
     • Throttling: “max X runs per minute for this tenant.”
     • Prioritization: “these workflows take precedence under load.”

4. Manual log-grepping and bespoke replays

   • With QStash alone:
     • To debug a bad run, you grep logs across your API, workers, and QStash.
     • To replay, you might:
       • Manually trigger the endpoint with reconstructed payloads.
       • Write ad-hoc scripts to requeue jobs.
   • With Inngest:
     • Traces show the full run with step inputs/outputs and structured logs.
     • Replay lets you re-run exactly the failed steps with the original inputs.
     • Bulk Cancellation lets you stop bad runs en masse when a bug slips into production.

---

Final Verdict

If your world is “stateless HTTP endpoints that should be called on a schedule with some retries,” Upstash QStash is a clean, low-friction fit. The moment you introduce multi-step workflows, tenant-aware flow control, or the need to reliably resume from the last good step, QStash starts to look like a building block, not the system.

Inngest is built for that next stage: workflows, agents, endpoints, background jobs—however it’s written, wherever it runs—expressed as code with inngest.createFunction() and step.run(), durable by default, and observable via Traces and Replay. You don’t have to rebuild workers, queues, idempotency, retries, and admin tools just to keep cron jobs and webhooks from breaking under real-world complexity.

Use QStash when you truly only need cron + retries. Reach for Inngest when you care about multi-step state, resume, and being able to query, cancel, or replay your workflows without turning your team into an infrastructure group.

---

Next Step

Get Started