Trigger.dev 成本节约分析技能：优化任务运行配置，降低云计算开支

trigger-cost-savings by triggerdotdev/skills

315 周安装量

18 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/triggerdotdev/skills --skill trigger-cost-savings

自动化云服务性能优化

🇨🇳中文介绍

Trigger.dev 成本节约分析

分析任务运行和配置，寻找成本降低机会。

前提条件：MCP 工具

此技能需要 Trigger.dev MCP 服务器 来分析实时运行数据。

检查 MCP 可用性

在分析之前，请验证以下 MCP 工具是否可用：

list_runs — 使用筛选器（状态、任务、时间段、机器规格）列出运行记录
get_run_details — 获取运行日志、持续时间和状态
get_current_worker — 获取已注册任务及其配置

如果这些工具不可用，请指导用户：

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.

如果没有 MCP 工具，请不要继续进行运行分析。您仍然可以审查源代码以查找静态问题（见下文静态分析部分）。

加载最新的成本节约文档

在给出建议之前，请获取最新的指导：

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

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

步骤 1：静态分析（源代码）

扫描项目中的任务文件，查找以下问题：

机器规格过大 — 任务使用 large-1x 或 large-2x 但没有明确需求
缺少 maxDuration — 任务没有执行时间限制（存在失控成本风险）
重试次数过多 — maxAttempts > 5 且未对已知故障使用 AbortTaskRunError
缺少防抖 — 高频触发器没有配置防抖
缺少幂等性 — 支付/关键任务没有幂等性密钥
使用轮询而非等待 — 使用 setTimeout/setInterval/sleep 循环而非 wait.for()
等待时间过短 — wait.for() 时间 < 5 秒（未设置检查点，浪费计算资源）
使用顺序执行而非批量执行 — 多个 triggerAndWait() 调用本可以使用 batchTriggerAndWait()
计划任务过于频繁 — 计划任务的运行频率超出必要

步骤 2：运行分析（需要 MCP 工具）

使用 MCP 工具分析实际使用模式：

2a. 识别高成本任务

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

总计算时间（持续时间 x 运行次数）高的任务
失败率高（浪费重试）的任务
在大型机器上运行但持续时间短（资源配置过高）的任务

2b. 分析失败模式

list_runs with status: "FAILED" or "CRASHED"

对于高失败率任务：

检查失败是可重试的（暂时性）还是永久性的
对于已知的不可重试错误，建议使用 AbortTaskRunError
计算失败重试浪费的计算资源

2c. 检查机器利用率

get_run_details for sample runs of each task

将实际资源使用情况与机器预设进行比较：

如果任务在 large-2x 上运行且持续时间始终 < 1 秒，则资源配置过高
如果任务是 I/O 密集型（API 调用、数据库查询），则很可能不需要大型机器

2d. 审查计划任务频率

get_current_worker to list scheduled tasks and their cron patterns

标记可能过于频繁的计划任务。

步骤 3：生成建议

将发现结果以优先级列表形式呈现，并附上预估影响：

## 成本优化报告

### 高影响
1.  **调整 `process-images` 任务机器规格** — 当前使用 `large-2x`，平均运行时间 2 秒。
   切换到 `small-2x` 可将此任务的成本降低约 16 倍。
   ```ts
   machine: { preset: "small-2x" }  // was "large-2x"

为 sync-user-data 添加防抖 — 847 次/天，经常突发触发。

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

低影响 / 最佳实践

为 generate-report 添加 maxDuration — 未配置超时时间。

maxDuration: 300 // 5 分钟

## 机器预设成本（相对值）

较大的机器每秒钟计算成本按比例更高：

| 预设 | vCPU | 内存 | 相对成本 |
|--------|------|-----|---------------|
| micro | 0.25 | 0.25 GB | 0.25x |
| small-1x | 0.5 | 0.5 GB | 1x (基准) |
| 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 |

## 关键原则

- **超过 5 秒的等待是免费的** — 设置了检查点，不收取计算费用
- **从小开始，逐步扩展** — 默认的 `small-1x` 适用于大多数任务
- **I/O 密集型任务不需要大型机器** — API 调用、数据库查询在网络等待上
- **防抖对高频任务节省最多** — 将突发运行合并为单次运行
- **幂等性防止重复工作** — 对于昂贵的操作尤其重要
- **`AbortTaskRunError` 停止浪费性的重试** — 不要重试永久性故障

有关详细策略和代码示例，请参阅 `references/cost-reduction.md`。

🇺🇸English

Trigger.dev Cost Savings Analysis

Analyze task runs and configurations to find cost reduction opportunities.

Prerequisites: MCP Tools

This skill requires the Trigger.dev MCP server to analyze live run data.

Check MCP availability

Before analysis, verify these MCP 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 these tools are not available , instruct the user:

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.

Do NOT proceed with run analysis without MCP tools. You can still review source code for static issues (see Static Analysis below).

Load latest cost reduction documentation

Before giving recommendations, fetch the latest guidance:

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

Use the fetched content to ensure recommendations are current. If the fetch fails, fall back to the reference documentation in references/cost-reduction.md.

Analysis Workflow

Step 1: Static Analysis (source code)

Scan task files in the project for these issues:

Oversized machines — tasks using large-1x or large-2x without clear need
MissingmaxDuration — tasks without execution time limits (runaway cost risk)
Excessive retries — maxAttempts > 5 without AbortTaskRunError for known failures
Missing debounce — high-frequency triggers without debounce configuration
Missing idempotency — payment/critical tasks without idempotency keys
Polling instead of waits — setTimeout/setInterval/sleep loops instead of wait.for()

Step 2: Run Analysis (requires MCP tools)

Use MCP tools to analyze actual usage patterns:

2a. Identify expensive tasks

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

Look for:

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"

For high-failure tasks:

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

Compare actual resource usage against machine preset:

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

Flag schedules that may be too frequent for their purpose.

Step 3: Generate Recommendations

Present findings as a prioritized list with estimated impact:

## 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

Add debounce tosync-user-data — 847 runs/day, often triggered in bursts.
```
debounce: { key: `user-${userId}`, delay: "5s" }
```

Low Impact / Best Practices

AddmaxDuration 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
- **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.

Weekly Installs

315

Repository

triggerdotdev/skills

GitHub Stars

First Seen

Mar 3, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

codex313

cursor312

github-copilot312

gemini-cli311

kimi-cli311

opencode311

Azure 升级评估与自动化工具 - 轻松迁移 Functions 计划、托管层级和 SKU

68,100 周安装

Short waits — wait.for() with < 5 seconds (not checkpointed, wastes compute)

Sequential instead of batch — multiple triggerAndWait() calls that could use batchTriggerAndWait()

Over-scheduled crons — schedules running more frequently than necessary