Trigger.dev review: serverless background jobs
Trigger.dev review: serverless background jobs
Trigger.dev is the right pick in 2026 if you want durable, code-first background jobs that survive deploys, restarts, and 30-minute LLM calls without spinning up your own queue. v3 (the rewritten Workers runtime) is genuinely production-ready for AI workflows, scheduled tasks, and webhook fan-outs. Skip it if you only need a 5-second cron, or if every job in your app finishes in under 10 seconds (Vercel cron or Inngest will be cheaper).
That is the verdict. Here is the long version.
What Trigger.dev actually is
Trigger.dev is an open-source background-jobs platform for TypeScript teams. You write tasks in your own repo (a tasks/ folder, usually), deploy them with npx trigger.dev@latest deploy, and they run on Trigger's managed Workers infrastructure. Each task gets a durable run, a retry policy, a structured log stream, and a visual run view in the dashboard.
The big shift in v3 (released late 2024 and stabilised through 2025) was the "Workers" model. Jobs no longer time out at 5 minutes. A single task can now run for hours, idle on an external API call without burning compute, and resume cleanly after a server restart. This is the architecture you want for anything that calls OpenAI, Claude, or a long-running scraping pipeline.
It competes most directly with Inngest, Hatchet, Defer, and a roll-your-own BullMQ + Redis stack. It is not trying to be a workflow engine like Temporal, and it is not a Vercel cron replacement for tiny jobs. The sweet spot is "background work that is too important to lose, too long for a serverless function, and too annoying to operate yourself."
Pricing (as of late 2025/early 2026)
Trigger.dev has a usage-based pricing model with three published tiers. Verify numbers on their site before you commit; AI infra pricing moves quarterly.
| Plan | Monthly price | Included runs | Concurrent runs | Notes |
|---|---|---|---|---|
| Free / Hobby | $0 | ~10k runs/mo | Low (around 5 concurrent) | Self-host option also free |
| Pro | ~$20/mo base | Higher run quota + usage-based on top | Higher concurrency | Most small teams land here |
| Enterprise | Custom | Custom | Custom | SOC2, SSO, dedicated support |
Hidden costs to plan for:
- Compute per second on long runs. Anything that idles waiting on an LLM still counts against compute-second metering. For a workflow that hits Claude or GPT-4o for 90 seconds, expect to be billed for that wall-clock time even though your CPU is doing nothing. Inngest handles this slightly differently with their step-function model.
- Egress and storage for run logs and artifacts. Trivial at small scale, real at high volume.
- Self-hosting, if you go that route, costs whatever your infra costs (think one small Postgres + a Docker host). The OSS version is feature-parity with cloud for most jobs.
The strongest features
These are the things Trigger.dev does meaningfully better than the alternatives we have tested.
1. Durable, long-running tasks without writing a state machine
In v3 you can write this:
export const enrichLead = task({
id: "enrich-lead",
run: async (payload: { leadId: string }) => {
const lead = await db.lead.findUnique({ where: { id: payload.leadId } })
const enriched = await claude.messages.create({ /* 60s LLM call */ })
await db.lead.update({ data: { enriched }, where: { id: lead.id } })
},
})
That function can run for 30 minutes. If the Worker crashes mid-run, Trigger replays it from a checkpoint. You did not have to model steps explicitly. Inngest forces you to wrap each pause in step.run() or step.sleep(); Trigger lets you write plain async code and handles checkpointing under the hood. For LLM pipelines that branch dynamically, this is the cleaner mental model.
2. The local dev experience is the best in the category
Running npx trigger.dev@latest dev starts a tunnel between your local task code and the cloud dashboard. You write a task, save the file, and it appears in the dashboard ready to test. Triggering a run from the UI executes your local function, with breakpoints, hot reload, and full log streaming. This loop is 5x faster than any queue-based setup we have tried. It is the single feature that turns Trigger into a tool engineers actually want to use rather than tolerate.
3. The run dashboard is genuinely useful
Every run shows the full payload, every log line with structured filtering, the retry history, the parent and child task tree (for fan-outs), and a flamegraph of where time went. You can re-run any task from any historical run with one click. BullMQ has nothing close to this without buying Bull Board Pro and writing your own observability glue.
4. Schedules, webhooks, and triggers in one place
The same SDK that defines a task() also defines schedules.task() (cron) and webhook receivers. You do not need a separate Quirrel for crons plus a webhook handler in Next.js plus a queue for the work. Define the trigger and the task in the same file, deploy once, done. For teams evaluating Inngest vs Trigger, this consolidation is usually the deciding factor.
5. Open source, with a real self-host story
The repo is MIT-licensed and the self-hosted version genuinely works in production. We have seen teams run it on a single Hetzner box with Postgres + Redis for under $20/month, handling several hundred thousand runs. That is rare in the workflow-engine space. Hatchet has a similar story; Inngest does not (their OSS dev server is for local use only, prod is cloud-only).
The weaknesses
Honest read on where Trigger.dev hurts.
Cold starts on the Worker fleet
The first run after a few minutes of idleness can take 2 to 5 seconds to start. If your task is "send a webhook ack in under 1 second", this matters. For most background work it does not, but be aware before you wire Trigger into a synchronous request path.
TypeScript-only
If your backend is Python, Go, or Ruby, Trigger.dev is not for you. They have hinted at multi-language support but nothing has shipped. Hatchet (Python + TypeScript) or Temporal (everything) are better picks if your stack is not TS.
v3 migration was painful for v2 users
Teams on v2 had to rewrite tasks for the Workers runtime. The new SDK is cleaner, but if you adopted Trigger in 2023 and never upgraded, budget a sprint to migrate. New adopters start on v3 and are unaffected.
Documentation has gaps on advanced patterns
The "happy path" docs are great. The moment you want to do something subtle (idempotency keys across task families, concurrency keys that span queues, complex retry-with-backoff that ignores certain error types), you end up reading source or asking in Discord. The Discord is responsive, but you will need it.
Pricing surprises at high volume
Several teams have reported bills that grew faster than expected once they crossed ~1M runs/month. The compute-second billing on long-running tasks is the usual culprit. If you are doing high-volume short tasks, BullMQ on your own Redis will be cheaper. If you are doing low-volume long tasks (AI workflows), Trigger is fine.
How it compares
A short, honest comparison against the realistic alternatives.
| Tool | Best for | Where it wins | Where it loses |
|---|---|---|---|
| Trigger.dev | Long AI workflows, TypeScript teams, durable jobs | Local dev loop, durable runs without step functions, OSS + cloud | TS-only, cold starts, compute-second pricing at scale |
| Inngest | Event-driven workflows, step-functions, observability | Mature step-function API, great for event fan-out, generous free tier | Forces step decomposition, OSS limited to dev mode |
| Hatchet | Self-hosted teams, Python + TS shops | Multi-language, durable, real OSS | Smaller community, less polished UI |
| BullMQ + Redis | High-volume short jobs, full control | Cheapest at scale, no vendor lock | You build everything: dashboards, retries, alerts, deploys |
| Temporal | Mission-critical workflows, polyglot teams | Battle-tested at scale, every language | Steep learning curve, heavy operational overhead |
| Vercel cron | Tiny scheduled tasks | Zero setup if you are already on Vercel | 10-second timeout, no retries, no observability |
Quick decision rules we use:
- "We are TypeScript, we ship AI features, we want a managed dashboard": Trigger.dev.
- "We are event-driven and want strict step functions with replays": Inngest.
- "We are Python or polyglot and want OSS": Hatchet (or Temporal if you have the ops budget).
- "We have a strong infra team and want the cheapest option at scale": BullMQ.
- "We need a 5-line cron that runs once a day": Vercel cron or your platform's native scheduler.
If you are still picking a hosting platform underneath any of these, our take on the best deployment platforms for startups walks through where each one fits.
Who should buy Trigger.dev
The shortlist of teams where Trigger is the obvious right call:
- TypeScript SaaS teams shipping AI features. Anything that calls an LLM, waits, branches on the result, calls another LLM. The durable-task model is built for this.
- Founders running webhook-heavy integrations. Stripe, Linear, GitHub, Slack. Trigger gives you per-event observability and replay without writing it yourself.
- Teams scheduling tasks they cannot afford to silently fail. Daily billing reconciliation, weekly report generation, monthly data exports. The dashboard makes failures impossible to miss.
- Anyone migrating off BullMQ because the on-call pages got old. You give up some cost efficiency, you get a fully managed control plane.
Skip Trigger.dev if:
- Your stack is not TypeScript and you do not plan to add a TS worker.
- Every background job in your app completes in under 5 seconds (Vercel cron or a simple SQS worker is cheaper).
- You run a very high-volume queue (millions of short jobs per day) where cents per run matters more than DX.
What to do next
Three steps, in order:
First, install the SDK locally and write one task. Pick a workflow you already have hacked together (a manual cron job, a Vercel function that times out, a shell script someone forgot about) and rewrite it as a Trigger task. Use npx trigger.dev@latest dev to test it locally with the dashboard. This takes under an hour and tells you everything you need to know about the DX fit.
Second, run a 7-day shadow test in production. Trigger your existing job and a Trigger.dev mirror of it in parallel. Compare the dashboards, the failure modes, the recovery story when something breaks. We did this for a Resend email-pipeline migration and the dashboard alone justified the switch. If you are evaluating the email side of that pipeline too, our Resend review for transactional email covers what to look at.
Third, audit the rest of your background-job stack honestly. Most teams have 4 to 6 places where async work happens (Vercel cron, GitHub Actions, a Render worker, a forgotten Heroku scheduler, BullMQ, the marketing automation tool). Consolidating onto one platform is almost always worth a sprint. If you want a second opinion on whether to do it yourself or book an engineer for a week, audit your tooling with Ship or Skip gives you an honest grade on what is worth keeping.
If you have decided to migrate but do not have the bandwidth to do it yourself, you can book a mid engineer on Cadence ($1,000/week) and have the BullMQ-to-Trigger migration shipped in one sprint. Every engineer on Cadence is AI-native by default, vetted on Cursor and Claude Code fluency before they unlock bookings, so the LLM-pipeline parts of the work move fast. 48-hour free trial; if the fit is wrong, you replace them. Median time to first commit across the platform is 27 hours.
The Cadence connection (brief)
Trigger.dev tasks tend to be the spine of AI features in modern SaaS apps. Every engineer on Cadence has shipped at least one durable workflow on Trigger, Inngest, or Hatchet; we test for it in the voice interview. If you want to compare the AI-platform layer above your job queue, our take on the best AI agent platforms for developers is the companion read to this one.
FAQ
Is Trigger.dev worth the money?
Yes, for TypeScript teams running background jobs that matter. The Pro plan at ~$20/month plus usage is cheaper than the engineering time you would spend building and maintaining a comparable dashboard, retry layer, and observability stack on BullMQ. At very high volume (millions of short jobs), the math flips and self-hosted Redis wins.
Trigger.dev vs Inngest: which should I pick?
Pick Inngest if you want strict step-function decomposition with named replays and event-driven fan-out as your primary pattern. Pick Trigger.dev if you want to write plain async TypeScript and let the platform handle checkpointing, and if local dev velocity matters more to you than step-level granularity. Both are excellent; the decision usually comes down to how your team thinks about workflows.
Can I use Trigger.dev for free?
Yes. The cloud free tier covers around 10k runs per month for hobby projects. The self-hosted version is MIT-licensed and free forever; you only pay for the infra you run it on (a small Postgres + a Docker host, usually under $20/month).
Does Trigger.dev support Python?
Not as of early 2026. The SDK is TypeScript-only. If your backend is Python, look at Hatchet (Python + TypeScript) or Temporal (multi-language). Some teams run a thin TS worker that calls into a Python service over HTTP, but that adds operational complexity.
How long can a Trigger.dev task run?
Up to several hours on v3. The Workers runtime checkpoints state and resumes after restarts, so a task that idles on a slow LLM call or a long-polling API does not burn compute the whole time. This is the main reason teams move off Vercel functions (10-second to 5-minute hard caps) onto Trigger.
Is Trigger.dev good for cron jobs?
For substantial recurring work (nightly reports, data syncs, batch enrichment), yes. The schedules.task() API is clean and the dashboard shows every historical run. For a tiny job that runs once a day and pings a webhook, your platform's built-in scheduler is simpler and probably free.