Your cron jobs should do more than run.

Schedule functions that sleep, fan-out, retry, and recover on any deploy—not just one cloud's cron. Trace every run.

Read the docsBuild for free

Did your cron finish?

Platform crons fire and forget. You rarely know if the job succeeded, how long it took, or why it failed at 3am.

  • No observability

    Did it finish? Was the output correct? You shouldn't need custom logging to know.

  • No retries

    Fail halfway and it's gone—wait for the next schedule, or write your own recovery.

  • No directives

    Can't sleep mid-run, fan out parallel jobs, or cancel from business logic.

  • Can't do more than run

    A schedule alone isn't orchestration—no steps, waits, or recovery path.

In Practice

Replace your setup with one line of code

A single trigger in your existing codebase can replace your entire cron setup. Inngest handles scheduling, retries, timezone support, and observability.

inngest/functions/weekly-digest.ts
// Runs every Friday at 12pm Paris time — with full observability and retries
export const weeklyDigest = inngest.createFunction(
  { id: "weekly-digest" },
  { cron: "TZ=Europe/Paris 0 12 * * 5" },
  async ({ step }) => {
 
    // Load all users — this step retries independently if it fails
    const users = await step.run("load-users", async () => 
      db.query("SELECT * FROM users")
    );
 
    // Fan-out: send one event per user, triggering parallel email jobs
    await step.sendEvent(
      "fan-out-digests",
      users.map(u => ({
        name: "app/send.weekly.digest",
        data: { user_id: u.id, email: u.email }
      }))
    );
 
    // Done — each email job runs in parallel with its own retries
  }
);
 
// Dynamic scheduling: run at a user-defined time
export const sendReminder = inngest.createFunction(
  { id: "send-reminder" },
  { event: "reminder/scheduled" },
  async ({ event, step }) => {
    // Sleep until the user-specified timestamp, then run
    await step.sleepUntil("wait-for-time", event.data.remindAt);
    await step.run("send-notification", () => 
      notify(event.data.userId)
    );
  }
);

Inngest vs Step Functions vs Temporal for serverless

Step Functions lock you into AWS and often a visual builder. Temporal needs workers and a cluster. Inngest is infrastructure-agnostic: serverless orchestration on the deploy you already run.

Capability
Step Functions
Temporal
Inngest
Infrastructure model
AWS-managed state machine
Cluster + worker fleet
HTTP into your deploy
Serverless / edge fit
AWS Lambda–centric
Workers required
Native serverless
Vendor lock-in
AWS-only
Worker runtime ops
Infrastructure-agnostic
Workflow definition
ASL / visual builder
Code (SDK workflows)
Code in your repo
Cron + events together
Separate patterns
Custom schedules
One function
Human-in-the-loop waits
Task tokens / callbacks
Signals / updates
waitForEvent / sleep
Distributed retries
State transitions
Activity retries
Per-step retries
Local DX
Emulators / console
Local Temporal stack
One CLI command

Why teams choose Inngest for scheduled jobs

Everything forproduction pipelines

  • Fan-out at scale

    One cron fans out to many jobs—each with its own retries.

    See Docs

  • Infrastructure-agnostic

    Runs on your existing deploy. No workers to manage.

    See Docs

  • Schedule in timezones

    Prefix crons with TZ=America/New_York. DST handled for you.

    See Docs

  • Cancel before firing

    Cancel a sleeping run when a matching event arrives.

    See Docs

  • Mix cron and events

    Same function: run on a schedule, or trigger on demand.

    See Docs

  • Full visibility

    Step-level traces and failure reasons for every run.

    See Docs

What teams have built with Inngest to handle cron & scheduled jobs

Digest emails

Weekly or daily summaries sent to users. Fan-out from a single cron to thousands of individual sends, each retried independently.

OuttakeSee the example

Data sync & imports

Periodic syncs with third-party APIs, database imports, and report generation — with full observability into every run.

TripadvisorRead the docs

User reminders

Schedule reminders at a user-defined time with step.sleepUntil(). Cancel automatically if the user acts first.

ResendSee the example

Scheduled content

Publish blog posts, send announcements, go live with features at a specific time. Cancel if plans change — no code needed.

SoundCloudSee the example

Trial & subscription lifecycle

Fire a trial expiry at the exact moment it ends. Cancel automatically if the user upgrades before the deadline.

ZampRead the docs
See all customers →

FAQ

  • It is coordinating multi-step jobs—schedules, events, data workflows, and approvals—on serverless or container deploys without running your own queue workers. Inngest persists step state and retries so distributed serverless execution stays reliable across timeouts and deploys.

  • Your orchestration is not tied to one cloud's cron service or a visual workflow builder. Inngest invokes functions over HTTP on Vercel, AWS, GCP, or any HTTP server, so the same code runs wherever you deploy.

  • Step Functions are AWS-centric and often use ASL or a visual workflow builder. Temporal requires a cluster and worker processes. Inngest is infrastructure-agnostic: no workers to run, cron and events in one function, and per-step retries on your existing deploy.

  • Inngest is not just a cron service. It adds durable, step-based serverless workflow orchestration to scheduled jobs — so if a scheduled job fails mid-run, only the failed step retries, not the whole job.

  • Yes. Use step.sleep, step.sleepUntil, or step.waitForEvent to pause a run until an approval event arrives, then continue the same function. That covers HITL approval patterns without a separate state machine service.

  • Yes. You define a schedule directly in code using a cron expression, and Inngest triggers execution on time. No separate cron daemon, server, or infrastructure required.

  • Inngest queues missed runs and executes them as soon as your deployment is available. Runs are never silently skipped.

  • Yes. Inngest triggers scheduled jobs via HTTP, so they run on any serverless platform without a persistent process. Vercel's built-in cron limits don't apply.

  • Yes. A single event sent to Inngest can fan out to multiple functions running in parallel, each with their own retries and execution state. No custom pub/sub logic required.

  • Yes. A single Inngest function can be triggered by a cron schedule and an event. You can run a daily report automatically and trigger it immediately on demand without duplicating logic.

  • Every scheduled run has a full execution trace in the Inngest dashboard — start time, step duration, failures, and output. You don't need to dig through logs to confirm execution.