Trigger.dev

@trigger.dev list all unresolved errors from the last 7 days in our payment-processor task and group them by error message

Found 3 unresolved error groups in payment-processor: 1. "Stripe webhook signature validation failed" – 47 occurrences across v1.2.3 and v1.2.4, first seen 6 days ago, last occurred 2 hours ago. 2. "Database connection timeout after 5000ms" – 12 occurrences in v1.2.4 only, clustered between 3-4 days ago. 3. "Invalid currency code 'GPB' in line item" – 8 occurrences in v1.2.3, sporadic over the past week. All three remain in 'open' state. The Stripe signature issue shows the highest frequency and may warrant immediate investigation.

This example demonstrates the List Errors tool filtered by task, status, and time window. The MCP returns error groups with occurrence counts and version distribution, but you'll need separate Get Error calls to see full stack traces or mark errors as resolved. Useful for daily triage; be aware that high-traffic tasks can generate hundreds of error groups.

@trigger.dev batch-trigger our send-welcome-email task for these 250 new user IDs and confirm the batch started successfully

Batch b_abc123xyz created successfully. Trigger.dev queued 250 runs of send-welcome-email (task ID: task_welcome_v2). Batch status: PENDING Runs enqueued: 250 Runs completed: 0 Runs failed: 0 Each run will receive its user ID as payload. The batch is now processing; you can poll batch status with the returned ID or wait for a webhook callback if configured. Estimated completion depends on your concurrency limits and task duration.

This example uses Batch Trigger Task to start many runs at once, which is more efficient than triggering individually. The MCP returns a batch ID immediately, but actual run results require a follow-up Get Batch Results call once the batch completes. Side-effect: 250 emails will be sent if the task succeeds. Ensure your Trigger.dev plan supports the concurrency you need.

@trigger.dev run a TRQL query to show me the average duration and success rate of our data-sync task over the past 30 days, broken down by week

Executed TRQL query against 1,847 runs of data-sync: | Week Starting | Avg Duration (s) | Success Rate | Total Runs | |---------------|------------------|--------------|------------| | 2025-01-06 | 12.4 | 98.2% | 412 | | 2025-01-13 | 13.1 | 97.8% | 438 | | 2025-01-20 | 14.7 | 96.5% | 451 | | 2025-01-27 | 15.2 | 95.9% | 546 | Trend: Duration is creeping up ~20% month-over-month, and success rate has dropped 2.3 percentage points. This suggests either growing dataset size or an emerging reliability issue worth investigating.

This example showcases Execute TRQL Query for custom analytics beyond Trigger.dev's dashboard. TRQL is read-only SQL against your run history, so you can aggregate, filter, and join run metadata. The AI can interpret trends and flag anomalies. Note that complex queries may time out on large datasets, and the schema is specific to Trigger.dev's data model—consult their TRQL docs for available tables and columns.

When Trigger.dev wins for troubleshooting failed background tasks

A 6-person SaaS team runs nightly data exports and webhook deliveries through Trigger.dev. When a customer reports missing data, the on-call engineer opens Switchy, asks the MCP to list errors from the past 48 hours filtered by the export task, then pulls the run details for the failed batch. The MCP surfaces the exact payload, retry attempts, and error group in one thread—no dashboard hopping. This works because Trigger.dev exposes granular run metadata and error grouping through its API. The trade-off: if your team isn't already using Trigger.dev as your job runtime, this MCP does nothing for you. If you are, the Get Run and List Errors tools collapse 4-click workflows into a single prompt, and the TRQL query tool lets you answer custom questions like 'how many runs failed in EU region last week' without writing SQL by hand.

When this MCP replaces manual batch-status checks

A 3-person data team triggers daily ML inference batches—each batch fans out to 200+ runs. Every morning standup, someone manually checks the Trigger.dev dashboard to confirm completion counts and scan for stragglers. With this MCP in Switchy, the team asks 'show me yesterday's inference batch status and any errors' and gets the batch summary, run counts, and error details in 10 seconds. The Get Batch and Get Batch Results tools are purpose-built for this: they return aggregated completion state and per-run outcomes without fetching every run individually. The boundary: if your batches are under 20 runs, the overhead of batch APIs isn't worth it—just list runs directly. Above 50 runs, the batch tools are faster and the MCP pays for itself in saved dashboard time every week.

When support needs task execution history without eng access

A 10-person support team fields tickets about delayed webhook deliveries. Historically, they ping engineering to check Trigger.dev logs. Now support reps open a shared Switchy thread, paste the customer's order ID, and ask the MCP to find recent runs for the webhook task filtered by that metadata. The Get Run tool returns timing, payload, and output URLs; if the run failed, List Errors surfaces the error group and occurrence count. This works because Trigger.dev indexes run metadata and the MCP exposes search by task and time window. The catch: if your support team needs to inspect payloads larger than a few KB, the presigned URLs require a second step—the MCP won't auto-fetch them. For 80 percent of 'did it run, did it fail' questions, though, this MCP turns a 15-minute eng interrupt into a 30-second self-service lookup.