Triage des problèmes de suivi des erreurs

Quand un utilisateur demande « qu'est-ce qui est cassé ? » ou veut un examen quotidien des erreurs, l'objectif est une courte liste priorisée de problèmes dignes de l'attention humaine — pas un dump de chaque problème actif. La plupart des projets ont des centaines de problèmes actifs ; les quelques-uns qui comptent sont généralement nouveaux (détectés dans les 24-48 dernières heures), en augmentation, ou affectant beaucoup d'utilisateurs distincts.

Outils disponibles

Flux de travail

Étape 1 — Choisir une fenêtre et un signal

Lisez la fenêtre de temps à partir des paroles de l'utilisateur. Valeurs par défaut si non spécifiées :

• « Aujourd'hui » / « ce matin » / « maintenant » → dateRange: { date_from: "-24h" }
• « Cette semaine » / « depuis lundi » → -7d
• Remise de garde → -24h

Choisissez ce que « compte » signifie :

• Nouveaux problèmes — orderBy: "first_seen", orderDirection: "DESC", fenêtre étroite. Capture les régressions introduites par des déploiements récents.
• Haut impact — orderBy: "users" classe par utilisateurs distincts affectés. Meilleur que les occurrences brutes pour la sévérité (une boucle bot produit beaucoup d'occurrences mais un utilisateur).
• Tendance — orderBy: "occurrences" sur une fenêtre courte vs une baseline plus longue pour détecter les pics.

Étape 2 — Récupérer la liste des candidats

Commencez étroit et élargissez si trop peu de problèmes reviennent :

posthog:query-error-tracking-issues-list
{
  "status": "active",
  "orderBy": "users",
  "orderDirection": "DESC",
  "dateRange": { "date_from": "-24h" },
  "limit": 20,
  "volumeResolution": 24
}

Faites correspondre volumeResolution à la fenêtre (24 buckets pour -24h, 14 pour -14d, etc.) pour que la sparkline de chaque ligne ait assez de résolution pour montrer un pic vs un état stable plat. Un seul bucket ne donne qu'un total, pas une forme.

Pour les problèmes uniquement nouveaux, lancez une requête parallèle avec orderBy: "first_seen" :

{
  "status": "active",
  "orderBy": "first_seen",
  "orderDirection": "DESC",
  "dateRange": { "date_from": "-24h" },
  "limit": 10
}

Si un projet mélange les SDK browser et server, la liste top-by-users est généralement noyée par les erreurs côté serveur (chaque invocation obtient souvent un distinct_id frais). Réduisez avec le filtre library — les valeurs correspondent à $lib du SDK, pas au nom du package npm, exemples :

• web — posthog-js (browser)
• posthog-node, posthog-python, posthog-ruby, posthog-go, posthog-php, posthog-java, posthog-elixir — SDK serveur
• posthog-edge — Cloudflare Workers / runtime edge
• posthog-ios, posthog-android, posthog-react-native, posthog-flutter — mobile

Étape 3 — Filtrer le bruit

La liste inclura du bruit connu. Avant de présenter, supprimez ou signalez :

• Les problèmes dont le volume est plat sur la fenêtre — ce ne sont pas des nouveaux, l'utilisateur les supporte déjà. Surfacez-les seulement s'ils sont en haut par utilisateurs.
• Les problèmes liés aux bots — si tous les événements proviennent de navigateurs headless ou d'agents crawlers, signalez pour suppression (suppressing-noisy-errors) au lieu de triage.

Si vous ne êtes pas sûr qu'un problème soit nouveau ou récurrent, comparez first_seen au début de la fenêtre :

• first_seen dans la fenêtre → nouveau, digne d'attention
• first_seen il y a des semaines mais en augmentation maintenant → régression digne d'attention
• first_seen il y a des semaines, volume plat → bruit de fond

Étape 4 — Ajouter du contexte pour les meilleurs éléments

Pour les 3-5 meilleurs candidats, récupérez un exemple d'exception pour que le résumé inclue une frame de stack et une URL, pas seulement un titre. Utilisez posthog:query-error-tracking-issue-events plutôt que du SQL brut — il retourne des champs normalisés ($exception_types, $exception_values, $current_url, navigateur/OS, $session_id) et défaut à onlyAppFrames: true pour supprimer le bruit vendor du stack :

posthog:query-error-tracking-issue-events
{
  "issueId": "<issue_id>",
  "limit": 1,
  "verbosity": "stack"
}

Si l'utilisateur veut voir ce que les utilisateurs faisaient, remettez à finding-replay-for-issue pour choisir le meilleur enregistrement lié. Ne récupérez pas les replays pour chaque problème trié — seulement ceux que l'utilisateur demande d'approfondir.

Étape 5 — Présenter la liste de triage

Commencez par un titre d'une ligne (« 3 nouveaux problèmes en 24h, 1 pic, 5 haut impact »). Puis un court tableau trié par votre signal choisi :

Pour chacun, suggérez l'une de : investiguer (investigating-error-issue), assigner (error-tracking-issues-partial-update), supprimer (suppressing-noisy-errors), fusionner (grouping-noisy-errors), ou résoudre si c'est déjà connu comme corrigé.

Conseils

• Un seul déploiement soulève souvent plusieurs problèmes nouveaux connexes. Si plusieurs problèmes nouveaux partagent un properties.$lib_version (ou properties.$exception_releases quand le SDK est configuré pour le remplir), présentez-les groupés — une décision de rollback repose sur le cluster, pas sur un seul problème.
• « Utilisateurs » est le bon proxy de sévérité pour les apps user-facing. Pour les services backend sans concept réel de distinct_id, réduisez à sessions ou occurrences.
• Ne faites pas d'auto-assign ou d'auto-resolve dans le triage. Présentez la liste et laissez l'utilisateur décider. Les actions bulk appartiennent à des skills dédiés.
• Si le projet utilise Inbox (posthog:inbox-reports-list), vérifiez d'abord — PostHog a peut-être déjà curé les problèmes les plus actionnables pour que vous évitez de les re-dériver.
• Fournissez l'URL du problème (/error_tracking/<id>) pour chaque ligne pour que l'utilisateur puisse aller directement à la page du problème s'il veut l'approfondir lui-même.