Your agent works on your laptop. Then you deploy it to a serverless function and it dies at fourteen minutes — mid-loop, halfway through a plan, holding a half-finished result you can't recover. Or the video render times out. Or the nightly batch job gets killed and you find out from a customer. Serverless was built for requests that finish in milliseconds; a lot of the interesting work founders ship now — agent loops, renders, fan-out jobs, anything that waits on another API — doesn't.

The usual fix is to stand up your own queue, a worker fleet, a retry policy, a dead-letter table, and a dashboard to see what's stuck. That's a week of undifferentiated infrastructure before your actual feature works in production.

What it is: Trigger.dev is an open-source platform for durable background jobs and AI agents, written for TypeScript. You write a normal async function, and it runs it with retries, queues, idempotency, and full observability — with no timeout.

What it is#

Trigger.dev lets you write long-running tasks as ordinary code and get production durability around them for free. Its own framing: build and deploy fully-managed AI agents and workflows, with "durable, long-running tasks with retries, queues, observability, and elastic scaling out of the box." The load-bearing difference from a plain function platform is right there in the docs — tasks can execute with absolutely no timeouts, unlike AWS Lambda, Vercel, and other serverless runtimes.

For agent work specifically, that means you can write an agent loop in the framework and models you already use, deploy it, and get durability, retrying, human-in-the-loop pauses, and observability without building any of it. A companion piece, Realtime, bridges your background task back to your app: subscribe to a run for live status, stream LLM responses straight to the user, and build reactive UIs powered by the work happening in the background.

It's genuinely open source — Apache-2.0, self-hostable — with a managed Cloud if you'd rather not run it.

Who it's for#

If you have work that's too long or too important to run inside a request, this is aimed at you: an agent that plans over minutes, a render pipeline, a scheduled batch job, a webhook that fans out into fifty downstream calls, an onboarding flow with retries and delays. If you've ever written the sentence "it works locally but times out in production," Trigger.dev is the shape of the fix.

Who it isn't for: if your background work is one tiny fire-and-forget email, a full jobs platform is more than you need — a queue primitive or your framework's built-in tasks will do. And it's TypeScript-first; if your stack is Python or Go end-to-end, the fit is weaker (you'd trigger tasks over the API rather than author them natively).

How to start#

Install the SDK and define a task — a task is just an async function with a durable wrapper around it:

// trigger/summarize.ts
import { task } from "@trigger.dev/sdk";

export const summarizeDoc = task({
  id: "summarize-doc",
  retry: { maxAttempts: 3 },          // automatic retries with backoff
  run: async (payload: { docUrl: string }) => {
    const text = await fetchDoc(payload.docUrl);        // could take minutes — no timeout
    const summary = await callLLM(text);                // retried if it 429s
    await saveSummary(payload.docUrl, summary);
    return { summary };                                  // observable in the dashboard
  },
});

Trigger it from anywhere in your app — an API route, another task, a cron schedule:

import { summarizeDoc } from "./trigger/summarize";

// returns immediately with a run handle; the work happens durably in the background
const handle = await summarizeDoc.trigger({ docUrl: "https://example.com/report.pdf" });

That's the whole model: normal code in run, .trigger() to enqueue, and the platform handles the queue, the retries, the idempotency, and the run history. Every run shows up in the dashboard with its logs, attempts, and payload — so a failure is something you see, not something a customer reports.

What it costs#

As of July 2026, Trigger.dev Cloud is metered on runs:

And because it's Apache-2.0, you can self-host the whole thing and pay only for the boxes it runs on.

The honest catch#

Three things to weigh. First, it's a real dependency to adopt, not a snippet: an SDK, a trigger/ directory, and a deploy step in your pipeline. That's the correct trade for durable infrastructure, but it's more than dropping in a library. Second, it's TypeScript-first — a great fit if that's your stack, a compromise if it isn't. Third, the meter counts runs, so a chatty design that fans one job into thousands of tiny runs can climb tiers faster than you'd guess; model your run volume before you commit, and batch where it's cheap to.

The takeaway#

If your agents and long jobs keep dying on serverless timeouts, Trigger.dev is the "stop building your own queue" button: write the function, wrap it in task(), get retries, queues, idempotency, and observability with no time limit — free to start, open source if you want to own it. It's the durable-execution half of the background image pipeline we built, and the reason an agent that waits on a long tool call can survive the wait.