trigger-cost-savings

# Trigger.dev Cost Savings Analysis Analyze task runs and configurations to find cost reduction opportunities. This skill pairs static source analysis with live run analysis via the Trigger.dev MCP server. ## Before you start: read the canonical guidance The authoritative, version-pinned cost guidance ships beside this skill. Read it first so your recommendations match the installed SDK version: - `@trigger.dev/sdk/docs/how-to-reduce-your-spend.mdx` — the canonical "reduce your spend" guide (machine sizing, idempotency de-dup, parallelism, retries, `maxDuration`, checkpointed waits, debounce). - Supporting references: `@trigger.dev/sdk/docs/machines.mdx`, `runs/max-duration.mdx`, `queue-concurrency.mdx`, `idempotency.mdx`, `triggering.mdx` (debounce + batch), `errors-retrying.mdx` (`AbortTaskRunError`). ## Prerequisites: MCP tools Live run analysis needs the **Trigger.dev MCP server**. Verify these tools are available: - `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 If they're not available, tell the user to install the MCP server: ```bash npx trigger.dev@latest install-mcp ``` Without the MCP tools you can still do the static source analysis below; do not fabricate run data. ## Analysis workflow ### Step 1: Static analysis (source code) Scan task files for: 1. **Oversized machines** — tasks on `large-1x`/`large-2x` without clear need. 2. **Missing `maxDuration`** — no execution-time limit (runaway-cost risk). 3. **Excessive retries** — `maxAttempts` > 5 without `AbortTaskRunError` for known-permanent failures. 4. **Missing debounce** — high-frequency triggers without debounce. 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()` under 5 seconds (not checkpointed, wastes compute). 8. **Sequential instead of batch** — multiple `triggerAndWait()` calls that could be `batchTriggerAndWait()`. 9. **Over-scheduled crons** — schedules firing more often than needed. ### Step 2: Run analysis (requires MCP tools) - **2a. Expensive tasks** — `list_runs` over `period: "30d"`/`"7d"`; find high total compute (duration × count), high failure rates, and large machines with short durations (over-provisioned). - **2b. Failure patterns** — `list_runs` with `status: "FAILED"`/`"CRASHED"`; separate transient (retryable) from permanent; suggest `AbortTaskRunError` for the latter; estimate wasted retry compute. - **2c. Machine utilization** — `get_run_details` on sample runs; if a `large-2x` task consistently runs in under a second, or is I/O-bound (API/DB), it's over-provisioned. - **2d. Schedule frequency** — `get_current_worker` to list cron patterns; flag schedules that are too frequent for their purpose. ### Step 3: Generate recommendations Present a prioritized report with estimated impact: ```markdown ## Cost Optimization Report ### High impact 1. **Right-size `process-images`** — currently `large-2x`, average run 2s. `small-2x` could cut this task's cost by ~16x. `machine: { preset: "small-2x" }` // was "large-2x" ### Medium impact 2. **Debounce `sync-user-data`** — 847 runs/day, often bursty. `debounce: { key: \`user-${userId}\`, delay: "5s" }` ### Low impact / best practice 3. **Add `maxDuration` to `generate-report`** — no timeout configured. `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. - **Webhook filters skip runs** — a webhook delivery starts no run when no subscriber's filter matches, so it costs no compute (a run already waiting for that webhook still resumes). Receiving webhooks has no separate charge. - **Start small, scale up** — the default `small-1x` is right for most tasks. - **I/O-bound tasks don't need big machines** — API calls and DB queries wait on the network. - **Debounce saves the most on high-frequency tasks** — it consolidates bursts into single runs. - **Idempotency prevents duplicate billed work** — especially for expensive operations. - **`AbortTaskRunError` stops wasteful retries** — don't pay to retry permanent failures. ## Version This skill is bundled inside `@trigger.dev/sdk` and read directly from `node_modules`, so it always matches your installed SDK version (see the adjacent `package.json`). The full cost documentation ships alongside it under `@trigger.dev/sdk/docs/`.