Background job

A background job is the unit of work in a [[task-queue]] system — a small piece of code that runs out-of-band from a request, may be retried on failure, and reports back via webhook / dashboard / database update.

Background jobs are short-to-medium-running async tasks: send a welcome email, render a PDF, call an LLM, kick off a cron-scheduled report. They differ from full workflows ([[durable-execution]]) by being mostly single-step; workflows are multi-step + stateful. Best practices: keep jobs small (< 5 min ideal), make them idempotent (safe to retry), use structured logging, capture errors to observability (Sentry / Datadog), expose a queue-depth metric to alert on backups. Frameworks differ on what they optimize: Sidekiq + BullMQ are throughput-first; Trigger.dev + Inngest add durable + replay; cloud queues (SQS, Cloud Tasks) trade richer UX for scale and managed-ness.

When to use background job

• Asynchronous post-request work.
• Scheduled cron-style jobs.

Common mistakes

• Making jobs too big — long-running jobs survive workers crashes poorly.
• Not making jobs idempotent — retries duplicate side effects.

FAQ

Related terms

• Task queue — A task queue is the backend pattern where work units are submitted to a queue, picked up by workers, and processed asynchronously — Celery, BullMQ, Sidekiq, AWS SQS, Cloud Tasks, Trigger.dev, Inngest are 2026 examples.
• Durable execution — Durable execution is the workflow / agent pattern where long-running multi-step processes survive crashes, restarts, and queue failures — state checkpointed after each step, resume from last checkpoint. Inngest, Temporal, Restate, AWS Step Functions are 2026 implementations.

Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/background-job.md.