Trigger.dev vs BullMQ: cost at production volume

Reproduce the usage calculation

The published small-1x rate is $0.0000338 per executing second, plus $0.000025 per run invocation. Ten seconds produces $0.000363 per run. At one million, ten million, and one hundred million runs, the modeled usage is $363, $3,630, and $36,300 respectively.

These are arithmetic examples, not measured throughput benchmarks. They assume every run uses the same machine and execution duration. A valid estimate for your application should group workloads by machine size and observed execution time, then sum the groups.

const invocationUsd = 0.000025
const small1xUsdPerSecond = 0.0000338
const executingSecondsPerRun = 10

for (const runs of [1_000_000, 10_000_000, 100_000_000]) {
  const usage = runs * (
    invocationUsd + executingSecondsPerRun * small1xUsdPerSecond
  )
  console.log(runs, usage.toFixed(2))
}
// 1000000 363.00
// 10000000 3630.00
// 100000000 36300.00

Include credits without counting the plan twice

Pro is listed at $50/month with $50 in included credits. A basic estimate is plan fee + max(0, eligible usage − credits) + add-ons. Thus $363 of eligible usage on that plan is $363 before add-ons, not $413. Confirm credit eligibility against your actual billing terms.

Keep a pricing worksheet with the review date and explicit exclusions. Separate task usage from additional seats, concurrency, and other purchased capacity. Recheck current prices before making a budget commitment; this article preserves the assumptions behind the calculation rather than promising a future bill.

Check whether the concurrency can deliver the volume

Average concurrency can be estimated from run count and execution time. For one hundred million runs at ten seconds each over 30 days, the calculation is 100,000,000 × 10 / 2,592,000 ≈ 386. This is an average capacity requirement under smooth arrivals; peak traffic requires more headroom.

Pro lists 200 included concurrent runs, with additional bundles of 50 at $10/month. In that smooth-arrival example, four bundles add 200 slots for $40/month, giving a modeled total of $36,340 before other charges. This does not guarantee the workload meets its latency target.

A nightly batch and a uniformly distributed workload can have the same monthly run count and very different required concurrency. Model the busiest interval and the acceptable queueing delay. A monthly cost projection that cannot physically finish the work on time is incomplete.

Measure execution time and checkpointed waiting separately

Trigger.dev checkpoints a run during durable waits. Waiting on subtasks, and wait.for or wait.until waits longer than five seconds, do not count toward compute usage. Freed compute is not freed concurrency: a time-based wait keeps its concurrency slot for roughly its first 60 seconds. Do not multiply the entire calendar duration of a multi-day workflow by the machine rate. Conversely, an ordinary awaited network request is not automatically the same thing as a durable wait.

The default small-1x machine has 0.5 vCPU and 0.5 GB RAM. A larger machine can cost more per second and still be cheaper for a CPU-bound operation if it finishes sufficiently faster. Benchmark representative payloads and failures rather than choosing a machine solely from its unit price.

Repeat the estimate for short, typical, and slow runs. Track observed retries and replayed work separately. The ten-second example excludes them; it should not be stretched into a claim about the cost of a long-running AI agent or a memory-heavy media pipeline.

Compare with your full BullMQ operating cost

On the BullMQ side, include worker compute, Redis, storage retention, availability, network transfer, observability, and operations. Durabull’s free-to-start hosted dashboard does not offset any of those costs; it is an operations interface, not a runtime. Existing spare worker capacity can reduce incremental cost, but a greenfield fleet needs its full cost included.

For I/O-heavy work, a BullMQ worker can handle multiple concurrent jobs subject to application resources and downstream limits. Do not equate one Trigger.dev machine with one permanently dedicated BullMQ process without measuring the workload. The compute architectures are different.

Choose Trigger.dev when its managed execution and developer workflow justify the cost for your team. Keep BullMQ when its runtime already meets your needs and the gap is operational visibility. Use a representative pilot to compare recovery, deployment effort, and cost together; a dashboard is not a drop-in replacement for a task runtime.

Common questions

Sources & review

Written by Durabull. Reviewed 20 October 2026 against the references below and Durabull’s implementation. Pricing examples are documented models, not measured benchmarks or vendor quotes.

Suggest a correction if a feature, price, or documented behavior has changed.

Compare the options

• Durabull vsTrigger.devReplaces BullMQ. Trigger.dev Cloud runs your task code and bills compute-seconds plus $0.000025 per run.
• Durabull vsInngestReplaces BullMQ. Cloud bills executions (run + each step). Official MCP inspects Inngest runs, not Redis queues.
• Durabull vsHatchetReplaces BullMQ. With a card on file, 1M runs and 1M events are free each month, then $30 per million runs.