Trigger.dev Cost Savings Analysis

Prerequisites: MCP Tools

Check MCP availability

• list_runs

  — list runs with filters (status, task, time period, machine size)

• get_run_details

  — get run logs, duration, and status

• get_current_worker

  — get registered tasks and their configurations

To analyze your runs, you need the Trigger.dev MCP server installed.

Run this command to install it:

  npx trigger.dev@latest install-mcp

This launches an interactive wizard that configures the MCP server for your AI client.

Load latest cost reduction documentation

WebFetch: https://trigger.dev/docs/how-to-reduce-your-spend

references/cost-reduction.md

Analysis Workflow

Step 1: Static Analysis (source code)

1. Oversized machines — tasks using

   large-1x

   or

   large-2x

   without clear need
2. Missing

   maxDuration

   — tasks without execution time limits (runaway cost risk)
3. Excessive retries —

   maxAttempts

   > 5 without

   AbortTaskRunError

   for known failures
4. Missing debounce — high-frequency triggers without debounce configuration
5. Missing idempotency — payment/critical tasks without idempotency keys
6. Polling instead of waits —

   setTimeout

   /

   setInterval

   /sleep loops instead of

   wait.for()

7. Short waits —

   wait.for()

   with < 5 seconds (not checkpointed, wastes compute)
8. Sequential instead of batch — multiple

   triggerAndWait()

   calls that could use

   batchTriggerAndWait()

9. Over-scheduled crons — schedules running more frequently than necessary

Step 2: Run Analysis (requires MCP tools)

2a. Identify expensive tasks

list_runs with filters:
- period: "30d" or "7d"
- Sort by duration or cost
- Check across different task IDs

• Tasks with high total compute time (duration x run count)
• Tasks with high failure rates (wasted retries)
• Tasks running on large machines with short durations (over-provisioned)

2b. Analyze failure patterns

list_runs with status: "FAILED" or "CRASHED"

• Check if failures are retryable (transient) vs permanent
• Suggest

  AbortTaskRunError

  for known non-retryable errors
• Calculate wasted compute from failed retries

2c. Check machine utilization

get_run_details for sample runs of each task

• If a task on

  large-2x

  consistently runs in < 1 second, it's over-provisioned
• If tasks are I/O-bound (API calls, DB queries), they likely don't need large machines

2d. Review schedule frequency

get_current_worker to list scheduled tasks and their cron patterns

Step 3: Generate Recommendations

## Cost Optimization Report

### High Impact
1. **Right-size `process-images` machine** — Currently `large-2x`, average run 2s.
   Switching to `small-2x` could reduce this task's cost by ~16x.
   ```ts
   machine: { preset: "small-2x" }  // was "large-2x"

Medium Impact

1. Add debounce to

   sync-user-data

   — 847 runs/day, often triggered in bursts.
   ts

   debounce: { key: `user-${userId}`, delay: "5s" }

Low Impact / Best Practices

1. Add

   maxDuration

   to

   generate-report

   — No timeout configured.
   ts

   maxDuration: 300  // 5 minutes

## Machine Preset Costs (relative)

Larger machines cost proportionally more per second of compute:

| Preset | vCPU | RAM | Relative Cost |
|--------|------|-----|---------------|
| micro | 0.25 | 0.25 GB | 0.25x |
| small-1x | 0.5 | 0.5 GB | 1x (baseline) |
| small-2x | 1 | 1 GB | 2x |
| medium-1x | 1 | 2 GB | 2x |
| medium-2x | 2 | 4 GB | 4x |
| large-1x | 4 | 8 GB | 8x |
| large-2x | 8 | 16 GB | 16x |

## Key Principles

- **Waits > 5 seconds are free** — checkpointed, no compute charge
- **Start small, scale up** — default `small-1x` is right for most tasks
- **I/O-bound tasks don't need big machines** — API calls, DB queries wait on network
- **Debounce saves the most on high-frequency tasks** — consolidates bursts into single runs
- **Idempotency prevents duplicate work** — especially important for expensive operations
- **`AbortTaskRunError` stops wasteful retries** — don't retry permanent failures

See `references/cost-reduction.md` for detailed strategies with code examples.