What is the difference among Inngest, a job queue and a cron job?

A cron job runs a task on a fixed time schedule. A job queue runs work in the background when your code enqueues a job, and you run the workers. Inngest runs durable functions triggered by events or schedules, split into steps that are retried and resumed independently, without you managing queues.

Choose cron for simple periodic work, such as nightly cleanup, report generation or backups. It fits tasks that are idempotent, short and fine to rerun on the next tick. If you need retries, state between steps or reaction to user actions, cron alone is not enough.

Choose a job queue to move slow or bursty work out of the request path, such as sending emails or resizing images. It suits high-volume, mostly single-step jobs with retries. You accept running and scaling the workers, and usually Redis or a cloud queue, yourself.

Choose Inngest for reliable multi-step workflows triggered by events, such as onboarding sequences, payment flows or AI pipelines. Each step is retried on its own and completed steps are not rerun. It also gives sleeps, waiting for events, concurrency and throttling without building that on a queue.

Plain cron has no retries; a failed run just waits for the next schedule unless you add your own logic. Job queues retry the whole job with configurable attempts and backoff. Inngest retries per step, so a failure in step three does not repeat steps one and two.

It means the platform records each completed step's result so the function can survive failures, deploys and long pauses. When the function resumes, finished steps are skipped and their saved output is reused. This lets a workflow sleep for days or retry one step without losing progress.

Inngest calls your function over HTTP, and each step.run result is memoized by its step ID. On later calls the function runs from the top again, but completed steps return their saved result instead of executing. So code outside steps can run many times, while step bodies run once per success.

They put side effects or non-deterministic code, like database writes, random IDs or current time, outside step.run. Because the function body re-executes on each step call, that code runs repeatedly and may give different values. Wrap side effects and non-deterministic values in steps.

Cron may rerun after a crash or overlap, queues usually deliver at least once, and Inngest retries steps that may have partly succeeded. So a job can run more than once. Use idempotency keys, upserts or a processed-ID check so a repeat does not double-charge or double-email.

Cron needs a scheduler such as crontab, a Kubernetes CronJob or a cloud scheduler. A job queue needs a broker like Redis or SQS plus worker processes you deploy, monitor and scale. With Inngest's managed service you expose an endpoint in your app, and Inngest handles queuing, state and scheduling.