Trigger.dev addresses a problem specific to modern serverless deployments: background jobs and long-running tasks don't fit naturally into a request/response serverless function's execution model, and Trigger.dev is built specifically to run that kind of task reliably — with retries, delays, and long durations — from code that lives directly in your application repository.
Trigger.dev is a background jobs platform for TypeScript applications, letting you define long-running or scheduled tasks directly in your codebase — with automatic retries, durable execution across failures, delays and waits, and full observability — designed specifically to fit into modern serverless deployment patterns where a typical function's execution time is bounded.
Why Durable Background Jobs Matter (and When a Simple Queue Suffices)
Durable background jobs matter for tasks needing to survive failures gracefully, run longer than typical serverless function timeouts, or need built-in retry and delay/wait semantics — a multi-step task that pauses waiting for an external event, or that needs guaranteed eventual completion despite transient failures, benefits from this durability rather than needing to be built from scratch.
A simple queue (a basic job queue with your own worker process) suffices for straightforward, short-running background tasks without complex retry or durability needs — Trigger.dev's additional durability and observability infrastructure is most valuable specifically for tasks complex or long-running enough to need it.
Getting Started with Trigger.dev
Defining a background task directly in your codebase:
import { task } from "@trigger.dev/sdk/v3";
export const processVideoUpload = task({
id: "process-video-upload",
run: async (payload: { videoId: string; url: string }) => {
const downloaded = await downloadVideo(payload.url);
const transcoded = await transcodeVideo(downloaded);
await uploadToStorage(transcoded, payload.videoId);
await notifyUser(payload.videoId, "processing-complete");
},
});
Triggering the task from your application code, with a delay:
await processVideoUpload.trigger(
{ videoId: "abc123", url: uploadedFileUrl },
{ delay: "10s" }
);
Core Trigger.dev Concepts Every Developer Should Know
Tasks defined directly in your codebase deploy alongside your application, keeping background job logic in the same repository, version control, and review process as the rest of your code — this avoids the split between application code and separately-managed job definitions that some background job platforms introduce.
Automatic retries and durable execution mean a task can survive transient failures (a downstream API timeout, a temporary network issue) without you building that resilience logic yourself — the platform handles retrying failed steps according to configured policy, which is exactly the kind of infrastructure code that's easy to get wrong if built from scratch.
Long-running tasks aren't bounded by typical serverless function timeout limits, since Trigger.dev's execution model is built specifically to handle tasks that run well beyond what a standard request/response function could — this matters for genuinely long tasks (video processing, large batch operations, multi-step workflows with waits) that wouldn't fit in a typical serverless function's execution window.
Delays and waits let a task pause execution — for a fixed duration, or until an external event — without holding compute resources the whole time, useful for workflows with a natural pause (waiting for a user action, a scheduled follow-up) that would otherwise require separate scheduling infrastructure to implement correctly.
Common Mistakes With Trigger.dev and How to Fix Them
Mistake 1: using a full background jobs platform for simple, short tasks that a basic queue would handle adequately, adding unneeded complexity. Fix: reserve Trigger.dev for tasks genuinely needing durability, long execution, or wait/delay semantics — a simple queue is sufficient for straightforward short tasks.
Mistake 2: not configuring retry policy deliberately for tasks with different failure tolerance, using one default retry behavior uniformly. Fix: configure retry behavior per task based on its actual idempotency and failure characteristics, since not every task should be retried the same way.
Mistake 3: building tasks that aren't idempotent, risking incorrect behavior if a retry re-executes a task that partially succeeded. Fix: design task logic to be safely retriable — checking for already-completed work before repeating it — since retries are a core part of the platform's reliability model.
When Should You Use Trigger.dev Instead of a Simple Background Job Queue?
Use Trigger.dev when tasks need to survive transient failures reliably, run longer than typical serverless timeouts allow, or require delay/wait semantics as part of the workflow logic. Use a simple background job queue for short, straightforward tasks without complex durability or scheduling needs, where the additional infrastructure Trigger.dev provides isn't necessary.
Trigger.dev in Production
Design task logic to be idempotent and safely retriable, since retry-based reliability is core to the platform's model, and configure retry policy deliberately per task rather than relying on one default uniformly. Reserve the platform for tasks that genuinely need durability, long execution, or wait semantics, using a simpler queue for straightforward short background work.
If you're building background processing for a serverless application, Trigger.dev is worth evaluating specifically where typical function timeouts or the need for reliable retries and delays would otherwise require you to build that infrastructure yourself.