Trigger.dev Pricing 2026: What You Actually Pay

Trigger.dev bills on two meters at once, and the one everybody forgets is the one that decides your invoice. In 2026 you pay a flat per-run fee plus a per-compute-second charge tied to the machine size your task runs on, both drawn down from a monthly credit balance. A light side project never leaves the free tier. A busy agentic workload can pass $1,000 a month, and roughly 99% of that is compute, not runs. This teardown walks the real numbers.

How does Trigger.dev actually bill in 2026?

Every plan is a credit bucket. The monthly fee is not a subscription on top of usage; it is prepaid usage. Free includes $5 of credits, Hobby ($10/month) includes $10, Pro ($50/month) includes $50. You draw compute and run fees from that balance, and anything past the balance bills on top.

The two meters that drain the bucket:

• Runs: $0.000025 per run, which is $0.25 per 10,000 runs. This line is almost never what hurts you.
• Compute: billed per second while the task is actively executing, priced by the machine preset. That is the line that hurts.

Here is the compute meter with the number the pricing page does not print: the cost of one full compute-hour.

Numbers pulled from the Trigger.dev pricing page, July 2026. Dev-environment runs are not charged.

What does a real monthly bill look like?

Three honest cohorts, each with stated assumptions. "Active seconds" means seconds the task is running code, not wall-clock.

The side project runs $2.53 of usage, well under the $5 free credit, so it pays nothing. The scaling cohort pays $1,027.50, of which $1,020 (99.3%) is compute. Runs are a rounding error at every size. Whenever a Trigger.dev bill surprises someone, it is the compute-second line, and the fix is upstream of the invoice.

Why does the same workload cost 40x more?

Hold the work constant and change only the machine. Take the growing-SaaS cohort's 800,000 active compute-seconds and re-price it across presets.

Same code, same throughput, a 40x spread from Micro to Large 2x. Most background jobs are I/O-bound, not CPU-bound, so they finish in the same wall-clock time on a small machine as on a large one. Default is Small 1x for a reason. Reach for Medium or Large only when a task is genuinely CPU or memory constrained, and measure before you do.

The one change that cut a bill 60%

Here is the mechanic almost no write-up quantifies. Trigger.dev checkpoints a run while it waits. From the pricing FAQ: waiting on a subtask does not count toward compute, and a timed wait via wait.for or wait.until longer than 5 seconds is checkpointed and does not count either. The meter is active compute, not elapsed time.

Now take the scale cohort. Say each 20-second run is really 8 seconds of work wrapped around 12 seconds of an in-process poll loop hitting an external API. That poll is billed, because the task is technically executing. Replace it with a native wait, and those 12 seconds stop counting.

• Before: 300,000 runs x 20s x $0.00017 = $1,020.00 of compute
• After: 300,000 runs x 8s x $0.00017 = $408.00 of compute
• Saved: $612 a month, a 60% cut on the compute line, from one code change, with identical throughput.

If your tasks sleep, poll, or wait on webhooks inside the function body, that idle time is money. Move it to a native wait and stop paying for nothing.

Trigger.dev vs Inngest: same job, different meter

The closest comparison is Inngest, and the two meters point in opposite directions. Inngest bills per execution, where one execution is a run or a single step, so a run with five step.run() calls costs six executions. Its Hobby tier is free to 50,000 executions, and Pro is $99/month including 1,000,000 executions, then $50 per million. Duration is irrelevant on Inngest: a 30-millisecond step and a 30-second step both cost one execution.

That gives a clean rule. Long-running, few-step tasks (video encoding, large LLM calls) lean cheaper on Inngest, because Trigger.dev keeps metering the seconds while Inngest charges one flat execution. Short, step-heavy tasks (a workflow with a dozen tiny fan-out steps) lean cheaper on Trigger.dev, because the compute-seconds stay tiny while Inngest's execution count multiplies. There is no universal winner. Match the meter to the shape of your work.

When does self-hosting win?

Both platforms are open source. Trigger.dev is self-hostable from its GitHub repo, and once you run it on your own infrastructure the per-second meter disappears. You pay raw compute for a VPS or your existing cluster instead. That flips the math for predictable, high-volume, long-duration workloads where the managed compute-second line would otherwise dominate, exactly the scale-cohort profile above.

The honest cost is operational. You now run Postgres, Redis, and a worker fleet, you own the upgrades, and you carry the pager. For most teams under a few hundred dollars a month, managed is cheaper once you price your own hours. We walk that crossover in detail in the build vs buy breakdown. Self-host when the compute meter, not your ops time, is the binding constraint.

Math check: at scale, compute is 99% of a Trigger.dev bill, one machine size is a 40x lever, and moving idle waits out of the function body cut our worked example 60% with zero throughput loss.