Analyse d'économies de coûts Trigger.dev

Analysez les exécutions de tâches et les configurations pour trouver des opportunités de réduction de coûts.

Prérequis : outils MCP

Cette compétence nécessite le serveur MCP Trigger.dev pour analyser les données d'exécution en direct.

Vérifier la disponibilité MCP

Avant l'analyse, vérifiez que ces outils MCP sont disponibles :

• list_runs — lister les exécutions avec filtres (statut, tâche, période, taille machine)
• get_run_details — obtenir les logs, la durée et le statut des exécutions
• get_current_worker — obtenir les tâches enregistrées et leurs configurations

Si ces outils ne sont pas disponibles, instruisez l'utilisateur :

Pour analyser vos exécutions, vous devez installer le serveur MCP Trigger.dev.

Exécutez cette commande pour l'installer :

  npx trigger.dev@latest install-mcp

Cela lance un assistant interactif qui configure le serveur MCP pour votre client IA.

Ne procédez PAS à l'analyse des exécutions sans les outils MCP. Vous pouvez toujours examiner le code source pour les problèmes statiques (voir Analyse statique ci-dessous).

Charger la dernière documentation de réduction de coûts

Avant de donner des recommandations, récupérez les derniers conseils :

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

Utilisez le contenu récupéré pour assurer que les recommandations sont actuelles. Si la récupération échoue, consultez la documentation de référence dans references/cost-reduction.md.

Flux de travail d'analyse

Étape 1 : Analyse statique (code source)

Analysez les fichiers de tâches du projet pour ces problèmes :

1. Machines surdimensionnées — tâches utilisant large-1x ou large-2x sans besoin clair
2. maxDuration manquant — tâches sans limite de temps d'exécution (risque de coûts incontrôlés)
3. Tentatives excessives — maxAttempts > 5 sans AbortTaskRunError pour les défaillances connues
4. Debounce manquant — déclencheurs haute fréquence sans configuration de debounce
5. Idempotence manquante — tâches de paiement/critiques sans clés d'idempotence
6. Polling au lieu d'attentes — boucles setTimeout/setInterval/sleep au lieu de wait.for()
7. Attentes courtes — wait.for() avec < 5 secondes (non checkpointées, gaspille du compute)
8. Séquentiel au lieu de batch — plusieurs appels triggerAndWait() qui pourraient utiliser batchTriggerAndWait()
9. Crons sur-planifiés — horaires s'exécutant plus fréquemment que nécessaire

Étape 2 : Analyse des exécutions (nécessite les outils MCP)

Utilisez les outils MCP pour analyser les modèles d'utilisation réels :

2a. Identifier les tâches coûteuses

list_runs avec filtres :
- period: "30d" ou "7d"
- Trier par durée ou coût
- Vérifier entre différents IDs de tâche

Recherchez :

• Tâches avec temps de compute total élevé (durée x nombre d'exécutions)
• Tâches avec taux de défaillance élevé (tentatives gaspillées)
• Tâches s'exécutant sur grandes machines avec durées courtes (sur-provisionnées)

2b. Analyser les modèles de défaillance

list_runs avec status: "FAILED" ou "CRASHED"

Pour les tâches à fort taux de défaillance :

• Vérifiez si les défaillances sont réessayables (transitoires) ou permanentes
• Suggérez AbortTaskRunError pour les erreurs non-réessayables connues
• Calculez le compute gaspillé par les tentatives échouées

2c. Vérifier l'utilisation des machines

get_run_details pour des exemples d'exécutions de chaque tâche

Comparez l'utilisation réelle des ressources contre le preset de machine :

• Si une tâche sur large-2x s'exécute régulièrement en < 1 seconde, elle est sur-provisionnée
• Si les tâches sont I/O-bound (appels API, requêtes DB), elles n'ont probablement pas besoin de grandes machines

2d. Examiner la fréquence de planification

get_current_worker pour lister les tâches planifiées et leurs modèles cron

Signalez les horaires qui peuvent être trop fréquents pour leur usage.

Étape 3 : Générer les recommandations

Présentez les résultats sous forme de liste priorisée avec impact estimé :

## Rapport d'optimisation des coûts

### Impact élevé
1. **Redimensionner la machine `process-images`** — Actuellement `large-2x`, exécution moyenne 2s.
   Le passage à `small-2x` pourrait réduire le coût de cette tâche d'environ 16x.
   ```ts
   machine: { preset: "small-2x" }  // était "large-2x"

Impact moyen

2. Ajouter debounce à sync-user-data — 847 exécutions/jour, souvent déclenchées en rafales.

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

Impact faible / Bonnes pratiques

3. Ajouter maxDuration à generate-report — Aucun timeout configuré.

   maxDuration: 300  // 5 minutes

Coûts des presets de machines (relatifs)

Les machines plus grandes coûtent proportionnellement plus par seconde de compute :

Principes clés

• Les attentes > 5 secondes sont gratuites — checkpointées, aucun coût de compute
• Commencez petit, montez en charge — le défaut small-1x convient à la plupart des tâches
• Les tâches I/O-bound ne nécessitent pas de grandes machines — appels API, requêtes DB attendent le réseau
• Le debounce économise le plus sur les tâches haute fréquence — consolide les rafales en exécutions simples
• L'idempotence prévient le travail dupliqué — particulièrement important pour les opérations coûteuses
• AbortTaskRunError arrête les tentatives inutiles — ne réessayez pas les défaillances permanentes

Consultez references/cost-reduction.md pour les stratégies détaillées avec exemples de code.