Background jobs

Move slow work out of the request/response cycle — sending emails, processing uploads, generating reports — without provisioning a queue, a worker fleet, or a dead-letter table. Jobs are just functions, deployed the same way as the rest of your app.

  • Trigger from an API call, event, or another job
  • Concurrency limits per job, not a shared global queue
  • Dead-letter handling for runs that exhaust retries

Scheduled jobs

Nightly syncs, billing runs, cleanup tasks — scheduled with standard cron syntax or plain-language intervals. Nodeflux handles clock drift and prevents overlapping runs if one execution takes longer than its interval.

  • Standard cron syntax or natural-language intervals
  • Overlap protection — a slow run won't double-fire
  • Timezone-aware scheduling, not just UTC

Event triggers

Send an event from your app, or point a webhook at Nodeflux, and matching workflows fire immediately. Signature verification and retry-on-failure are handled for you, so a flaky downstream call doesn't mean a lost webhook.

  • Fan-out: one event can trigger multiple workflows
  • Webhook signature verification built in
  • Replay any event that failed downstream

Retries & idempotency

A failed step retries on its own schedule with exponential backoff — you don't write the retry loop. Idempotency keys ensure that if a step already succeeded (like charging a card), a retry won't run it twice.

  • Configurable retry count and backoff per job
  • Idempotency keys scoped per step, not per job
  • Manual retry or replay from the dashboard

Durable steps

Each step in a job is checkpointed as it completes. If step four fails, steps one through three don't re-run on retry — Nodeflux resumes exactly where the job left off, which matters when step one charged a card.

  • Per-step checkpointing, not whole-job restarts
  • Sleep and wait-for-event steps for long-running flows
  • Parallel step execution where steps don't depend on each other

Observability

A failed job shouldn't mean digging through application logs to find out why. Every run captures its full input, output, and timing per step, so you can see exactly what happened and replay it with the same input.

  • Full input/output history per step, not just pass/fail
  • Search and filter runs by status, job, or time range
  • Replay a specific run with its original input

Frequently asked questions

Common questions about the product

Does Nodeflux require a separate workflow language?

No. Jobs are plain functions in TypeScript or Python, written and deployed alongside the rest of your application — there's no YAML or separate DSL to learn.

What happens if a step fails partway through a job?

Steps checkpoint independently. If step three of five fails, a retry resumes from step three — steps one and two don't re-run, which matters when an earlier step had a side effect like charging a card.

Can I trigger a job from a webhook?

Yes. Point a webhook at Nodeflux and it verifies the signature, queues the event, and retries your handler automatically if it errors — so a flaky downstream call doesn't mean a lost webhook.

How is this different from a cron job on a server?

A cron job on a single server has no retry logic, no overlap protection, and no record of what happened if it fails silently at 3am. Nodeflux handles drift correction, overlap protection, and gives you a full run history.

Do I need to self-host anything?

No. Nodeflux is fully managed — you deploy your functions, and Nodeflux handles scheduling, retries, and the infrastructure behind them.

Start building

Deploy your first background job and see it run.

Get started free

See the product

A walkthrough of jobs, scheduling, retries, and steps.

Explore the product

Check pricing

Usage-based, from a generous free plan.

View pricing