D’un compte neuf à une question résolue

Avant de commencer

Il vous faut une application capable d’émettre des requêtes HTTPS sortantes, et un endroit où poser deux variables d’environnement. C’est réellement tout : aucun agent à installer, aucun sidecar à faire tourner, aucun démon à maintenir en vie.

Il y a trois façons de se connecter, et la vôtre décide de ce que vous copierez dans la partie 2. Lisez d’abord ce tableau : c’est la décision que le reste de la page suppose prise.

Étape 1.1 — Créer le compte

Un formulaire. Le nom de l’organisation est celui que votre équipe verra dans la barre du haut ; ce n’est pas un domaine et il n’a pas à être unique. Votre propre nom est facultatif. Le mot de passe fait au moins 12 caractères, et les conditions d’utilisation comme la politique de confidentialité sont liées depuis la case qui les accepte.

Aucun moyen de paiement n’est demandé, ni maintenant ni plus tard sur l’offre gratuite. Le formulaire vous dit aussi où vos données seront hébergées avant que vous ne validiez.

snagspy.com → Get started → Create an account

Étape 1.2 — Confirmer votre adresse

Valider le formulaire crée le compte et envoie un seul e-mail, dont l’objet est « Confirm your SnagSpy address ». La page remplace le formulaire par une carte qui dit où il est parti. Rien d’autre ne se passe tant que vous n’ouvrez pas ce lien : impossible de se connecter avec une adresse non confirmée.

Le lien reste valable sept jours. En redemander un remplace le précédent : s’il en est arrivé plusieurs, utilisez le plus récent. S’il n’en est arrivé aucun, regardez les indésirables avant toute autre chose — l’expéditeur est alerts@snagspy.com.

Étape 1.3 — Se connecter

L’adresse et le mot de passe de l’étape 1.1. La première connexion arrive sur la page Overview de votre organisation, qui, pour un compte neuf, se résume surtout à la liste en image en haut de cette page.

snagspy.com → Sign in

Tout ce qui suit se passe dans l’application, et chaque étape nomme l’entrée du menu latéral où elle se trouve. Ce menu est groupé — Monitoring en haut, Management vers le bas — et les deux groupes que ce guide utilise le plus sont Management, pour configurer, et Monitoring, pour voir ce qui est arrivé.

Étape 2.1 — Ouvrir Projects

Un projet, c’est une application. Les problèmes, la conservation et les filtres à l’entrée lui sont tous rattachés, et le créer est ce qui vous donne un DSN — l’adresse vers laquelle votre application envoie. La plupart des équipes en créent un puis un second quand un deuxième service se met à remonter des données.

Projects est sous Management, l’avant-dernier groupe du menu latéral, et non sous Monitoring en haut. Faites défiler le menu si vous ne le voyez pas.

Menu latéral → Management → Projects

Étape 2.2 — À quoi ressemble une page Projects vide

Sur un compte neuf, la page le dit en toutes lettres. Deux cartes : l’une pour dire qu’il n’y a encore rien, et une carte New project avec un seul champ. Rien n’est à configurer avant d’en créer un.

Menu latéral → Management → Projects

Étape 2.3 — Le nommer et le créer

Nommez-le d’après l’application et non d’après l’environnement : staging et production tiennent dans un même projet, distingués par l’attribut deployment.environment que votre SDK envoie déjà. Un nom comme checkout-api vieillit mieux qu’un nom comme prod.

Saisissez le nom et cliquez sur Create project. Le projet apparaît aussitôt sur la même page, sans DSN pour l’instant.

Menu latéral → Management → Projects → New project

La liste sur votre tableau de bord confirme cette étape en lisant vos projets. Si elle montre encore Create your first project comme à faire, c’est que le projet n’a pas été créé — et non qu’il est passé inaperçu.

Étape 2.4 — Créer le DSN

La carte du nouveau projet indique « No DSN yet » sous Ingest keys. Rien ne peut envoyer vers un projet tant qu’il n’en a pas : c’est donc le clic qui rend le projet utilisable, le bouton Create DSN en haut à droite de la carte.

Un projet peut avoir plusieurs DSN — un par déploiement, par exemple — et chacun se révoque depuis cette liste. Commencez par un seul.

Menu latéral → Management → Projects → votre projet → Create DSN

Étape 2.5 — Le copier tout de suite

La création du DSN l’affiche en entier, une fois, dans un encadré Your DSN. Copiez-le avant de quitter la page. Ensuite, le projet n’en montre plus qu’un préfixe raccourci — assez pour distinguer deux clés, pas assez pour émettre. Vérifié en rechargeant la page : l’encadré a disparu et la liste montre les dix premiers caractères.

Le perdre n’a rien de dramatique — créez-en un autre et révoquez le premier — mais c’est un détour évitable. Collez-le quelque part en sécurité pour l’instant ; l’étape 2.6 dit quelle partie va où.

Menu latéral → Management → Projects → Create DSN (affiché une seule fois, à la création)

Étape 2.6 — Où le coller, et quelle partie

Dans l’environnement de votre application — là d’où viennent déjà ses autres variables : le bloc env d’un conteneur, un secret Kubernetes, les variables de configuration de votre plateforme, ou un fichier .env local sur un poste. Ni votre dépôt, ni votre code : le DSN change d’un projet à l’autre, le code non.

Collez-le entier. Vous n’avez pas à le découper : la variable d’en-tête accepte la chaîne complète, et l’autre variable dont un SDK OpenTelemetry a besoin est l’hôte d’ingestion, la même constante pour tout le monde, écrite en partie 3. L’ingestion accepte aussi la clé seule : une configuration plus ancienne qui ne porte que la clé continue de fonctionner.

C’est un identifiant en écriture seule. Il permet d’envoyer de la télémétrie dans ce seul projet et rien d’autre — jamais d’en lire — ce pourquoi l’application le dit sûr à embarquer dans un client. Il a tout de même sa place dans votre environnement plutôt que dans un commit public, parce qu’il change d’un projet à l’autre et que votre code ne devrait pas.

Partie 3 — Choisir votre porte d’entrée

L’ingestion parle l’OTLP standard sur HTTP : les traces sur /v1/traces, les logs sur /v1/logs, les métriques sur /v1/metrics, en protobuf ou en JSON. Tout ce qui exporte de l’OpenTelemetry peut donc lui envoyer avec deux réglages — l’endpoint et un en-tête — et c’est exactement ce que sont 3.A et 3.B. Aucun format propriétaire à apprendre.

Quelle que soit la voie, l’en-tête est la partie à écrire exactement. Il doit s’appeler Authorization, avec le schéma Bearer. Ce qu’il porte peut être votre DSN entier ou seulement la clé qu’il contient — l’ingestion accepte les deux et déduit le projet de la clé — il n’y a donc rien à extraire. Ce que l’ingestion n’accepte pas, c’est un en-tête sous un autre nom : cela, une clé révoquée et une clé mal saisie sont toutes refusées avec le même 401 et le même corps, « DSN is invalid or revoked », si bien que la réponse ne peut pas vous dire laquelle des erreurs vous avez faite. La partie 4.4, elle, le peut.

OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.snagspy.com
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20<votre DSN, exactement tel qu’affiché>
OTEL_SERVICE_NAME=checkout-api

Le %20 est une espace encodée, la forme que la spécification OpenTelemetry demande dans cette variable. Une espace littérale a aussi fonctionné dans les SDK Node.js, Python et Go lors des essais de cette page — les deux formes ont été envoyées avec un DSN entier et les six combinaisons ont été acceptées — donc si vous en avez déjà une, laissez-la. Les espaces autour de la valeur sont retirées à l’arrivée.

Étape 3.A.1 — Node.js

Deux paquets amont et rien de nous. L’exporter lit les variables ci-dessus dans l’environnement, si bien que le code ne nomme ni l’hôte ni la clé. C’est le programme qui a été exécuté avec un DSN créé à l’étape 2.4 ; le problème qu’il a produit est celui de la partie 4.

L’appel de shutdown à la fin compte plus qu’il n’y paraît : l’exporter regroupe les envois, et un processus qui se termine sans vider sa file perd ce qu’il retenait — y compris le plantage que vous vouliez justement voir.

import { NodeSDK } from '@opentelemetry/sdk-node'
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http'
import { trace, SpanStatusCode } from '@opentelemetry/api'

const sdk = new NodeSDK({ traceExporter: new OTLPTraceExporter() })
sdk.start()

const tracer = trace.getTracer('checkout')
await tracer.startActiveSpan('POST /checkout/confirm', async (span) => {
  try {
    const order = undefined
    return order.total            // l’échec volontaire
  } catch (err) {
    span.recordException(err)
    span.setStatus({ code: SpanStatusCode.ERROR, message: err.message })
  } finally {
    span.end()
  }
})

await sdk.shutdown()             // vider la file avant de quitter

Étape 3.A.2 — Python

La même forme avec les paquets Python amont. record_exception est ce qui fait du span une erreur que le tableau de bord regroupe ; un span en statut ERROR sans événement d’exception est une requête lente, pas un plantage.

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

provider = TracerProvider()
provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter()))
trace.set_tracer_provider(provider)

tracer = trace.get_tracer("checkout")
with tracer.start_as_current_span("POST /checkout/confirm") as span:
    try:
        order = None
        order["total"]                       # l’échec volontaire
    except Exception as exc:
        span.record_exception(exc)
        span.set_status(trace.StatusCode.ERROR, str(exc))

provider.shutdown()                          # vider la file avant de quitter

Étape 3.A.3 — Go

Modules amont uniquement ; rien n’est récupéré depuis notre dépôt. RecordError attache l’événement d’exception, SetStatus marque le span en échec, et Shutdown vide la file.

exporter, err := otlptracehttp.New(ctx)
if err != nil {
    log.Fatal(err)
}
provider := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter))
otel.SetTracerProvider(provider)
defer provider.Shutdown(ctx)                 // vider la file avant de quitter

_, span := otel.Tracer("checkout").Start(ctx, "POST /checkout/confirm")
err = errors.New("order total is nil")     // l’échec volontaire
span.RecordError(err)
span.SetStatus(codes.Error, err.Error())
span.End()

Étape 3.A.4 — Tout autre langage

Tout SDK OpenTelemetry — Java, .NET, Ruby, PHP, Rust et les autres — lit les trois mêmes variables de la partie 3 et envoie vers les trois mêmes chemins. Installez l’exporter OTLP/HTTP de votre langage, posez les variables, enregistrez une exception sur un span, et passez à la partie 4. Seuls Node.js, Python et Go ont été exécutés pour cette page ; les autres suivent la même spécification mais n’ont pas été lancés ici.

Si votre SDK se configure dans le code plutôt que depuis l’environnement, les deux valeurs sont l’endpoint https://ingest.snagspy.com et une table d’en-têtes à une seule entrée : Authorization, valant Bearer, une espace, et la CLÉ.

Étape 3.B — Un collector que vous faites déjà tourner

Ajoutez un exporter et placez-le sur les pipelines à dupliquer. L’application ne change pas du tout. En YAML, aucun encodage ne s’applique : l’en-tête s’écrit avec une vraie espace.

Gardez votre exporter actuel sur le même pipeline pendant que vous comparez les deux. Le guide OpenTelemetry de la documentation donne la configuration côte à côte complète.

exporters:
  otlphttp/snagspy:
    endpoint: https://ingest.snagspy.com
    headers:
      Authorization: Bearer ${SNAGSPY_DSN}

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/snagspy]

Étape 3.C — Notre propre SDK, pour une application navigateur

Si ce que vous instrumentez est un front, c’est le plus court des trois chemins : notre SDK JavaScript prend le DSN entier, en une seule chaîne, et fait le découpage lui-même — rien dans votre code ne touche à la clé ni à l’endpoint. Il installe aussi les gestionnaires d’erreurs non capturées et de rejets de promesses non gérés : le cas courant ne demande aucun appel explicite. Et il masque les valeurs ressemblant à des secrets avant que quoi que ce soit ne quitte le navigateur.

Le SDK Go est la seule exception de cette page, et elle est dite plutôt qu’escamotée : le chemin de son module, github.com/snagspy/sdk-go, n’existe pas encore comme dépôt, donc `go get` répond 404 (vérifié le 11 septembre 2026). Go récupère les sources depuis le chemin lui-même et le dépôt de la plateforme est privé : le SDK a donc besoin d’un dépôt public à lui. Pour Go, passez par la partie 3.A.3 — elle atteint le même tableau de bord avec des paquets amont, et c’est l’exemple que cette page a réellement exécuté.

import { init } from '@snagspy/replay/errors'

// Le DSN entier de l’étape 2.5, exactement tel qu’il s’est affiché.
const snagspy = init({ dsn: globalThis._importMeta_.env.VITE_SNAGSPY_DSN })

snagspy.captureException(new Error('première erreur depuis le navigateur'))

Le paquet est en ESM et embarque ses propres déclarations TypeScript. Le replay de session et le retour utilisateur sont des points d’entrée distincts de la même installation, documentés sur la page JavaScript navigateur.

Étape 4.1 — Provoquer une erreur

Ne prenez pas l’absence d’erreur pour un succès. Déployez le changement de la partie 3, puis provoquez un échec que vous reconnaîtrez : levez une exception sur une route que vous pouvez atteindre, lancez une requête dont vous savez qu’elle répond 500, ou exécutez le programme d’exemple tel quel — son échec volontaire est signalé dans le code.

Puis patientez quelques secondes. L’exporter regroupe les envois : un événement quitte le processus au rythme du regroupement ou à l’arrêt, selon ce qui vient en premier.

Étape 4.2 — Ouvrir Errors

Errors est sous Monitoring, en haut du menu latéral. L’événement apparaît sur une ligne : le type et le message de l’exception, la frame d’origine, le nombre d’événements et d’utilisateurs, et le moment. Les événements sont regroupés en problèmes selon leur origine, pas selon leur nombre — un deuxième échec identique rejoint cette ligne au lieu d’en ajouter une.

Menu latéral → Monitoring → Errors

Étape 4.3 — La liste est d’accord

De retour sur Overview, les deux premières lignes sont cochées, et chacune dit ce qu’elle a vu : le projet par son nom, et combien de problèmes ont été regroupés depuis ce que vous avez envoyé. C’est l’étape que le tableau de bord prouve au lieu de la supposer — il lit votre consommation de la période et ne coche que si le compteur d’événements a réellement dépassé zéro.

Menu latéral → Monitoring → Overview

Étape 4.4 — Si rien n’est arrivé

Séparez d’abord « ma requête n’est jamais partie » de « elle est arrivée et a été refusée ». L’hôte d’ingestion répond à un contrôle de vie sans aucun identifiant ; si ce contrôle échoue depuis la machine où tourne votre application, le problème est la sortie réseau — un pare-feu ou un proxy — et aucune configuration n’y changera rien.

Si le contrôle répond, la requête est arrivée, et les causes sont, par ordre de fréquence : l’en-tête ne s’appelle pas exactement Authorization avec le schéma Bearer ; la clé a été révoquée ou appartient à un autre projet ; la valeur a été tronquée à la copie ; ou l’exporter a mis en file et le processus s’est terminé avant de la vider. Les trois premières produisent le même 401 montré ci-dessous : vérifiez les trois au lieu de vous arrêter à la première.

curl -i https://ingest.snagspy.com/healthz
# HTTP/1.1 200 OK  {"status":"ok"}        — l’hôte est joignable d’ici

curl -i -X POST https://ingest.snagspy.com/v1/traces \
  -H "Content-Type: application/json" -H "Authorization: Bearer <votre DSN>" -d "{}"
# 200 {}                                    — accepté ; le problème est dans votre exporter
# 401 {"error":{"code":"invalid_dsn",...}}  — mauvais nom d’en-tête, ou clé fausse ou révoquée

Deux choses ne sont pas des causes, parce que les deux ont été éprouvées en les envoyant : les espaces autour de la valeur, que l’ingestion retire, et le DSN entier collé là où l’on pourrait croire que seule la clé va, que l’ingestion accepte.

Étape 5.1 — Choisir où les alertes vous parviennent

Une télémétrie dont personne n’est informé est une archive, pas de la surveillance. Alerts est sous Monitoring ; la carte Where to send them en bas de page prend soit une URL de webhook — les webhooks entrants Slack et Discord fonctionnent tels quels — soit une adresse e-mail. Choisissez le type, nommez-le, collez l’URL ou l’adresse, et cliquez sur Add destination.

L’adresse du webhook est contrôlée avant l’enregistrement : une adresse interne ou privée est refusée. Les alertes et les résumés par e-mail arrivent dans la langue de l’organisation, qu’il vaut la peine de régler en partie 9 si votre astreinte ne lit pas l’anglais.

Menu latéral → Monitoring → Alerts → Where to send them

Étape 5.2 — Ce qui est conservé ensuite

La ligne enregistrée montre le nom, le type et l’hôte — https://hooks.slack.com — et plus jamais l’URL complète du webhook, parce que cette URL est un identifiant et qu’elle est stockée chiffrée. Une adresse e-mail est affichée en entier : c’est un contact, pas un identifiant. Last success et Last failure se remplissent au fil des envois.

Menu latéral → Monitoring → Alerts → Where to send them

Étape 6.1 — Ce que connecter GitHub fait, et ne fait pas

Connecter un dépôt n’envoie pas d’erreurs ; c’est le SDK de la partie 3 qui s’en charge. Ce que cela envoie, ce sont des déploiements : un push sur la branche par défaut du dépôt est enregistré comme déploiement en production dont la version est le commit d’arrivée, avec le message, l’auteur et un lien de comparaison. C’est ce qui permet à la plateforme de répondre à « qu’est-ce qui a changé ? » — une erreur apparue trois minutes après un déploiement s’affiche à côté de lui sur la frise, et l’analyse de cause racine lit la même frise.

C’est un webhook de GitHub vers nous, signé avec un secret que vous choisissez, et configuré par projet. La plateforme ne détient aucun identifiant GitHub et ne récupère rien dans votre dépôt. Les pushes sur d’autres branches sont acceptés et ignorés : une branche de fonctionnalité n’apparaît jamais comme une version.

Slack et Discord ne sont pas sur cette page et ne manquent pas : ils reçoivent des alertes, ce qui est la partie 5. Un fournisseur ici envoie des déploiements vers nous, d’où le secret de signature que demande le formulaire.

Étape 6.2 — Choisir un secret de signature

Le secret est une chaîne que vous inventez et saisissez à deux endroits — ici et sur GitHub — pour que nous puissions vérifier que chaque livraison vient bien de votre dépôt. Il fait au moins 16 caractères ; trop court, la signature se casse par force brute à partir d’une seule livraison interceptée. Générez-en un aléatoire et gardez-le dans un gestionnaire de mots de passe jusqu’à l’étape 6.6, parce que SnagSpy ne le réaffichera pas.

openssl rand -hex 24

Étape 6.3 — Remplir la carte Connect a provider

Integrations est sous Management. La carte à droite demande le projet, le fournisseur — GitHub — le secret de signature de l’étape 6.2, et, facultatif, le nom du dépôt, simple étiquette pour distinguer les lignes. Cliquez sur Save Integration.

Enregistrer remplace tout secret déjà stocké pour ce projet et ce fournisseur, et les livraisons signées avec l’ancien cessent d’être acceptées. Seuls un propriétaire ou un administrateur voient cette carte.

Menu latéral → Management → Integrations → Connect a provider

Étape 6.4 — Copier l’URL de livraison

Le tableau a maintenant une ligne Connected pour GitHub, et sa colonne Delivery URL contient l’adresse à laquelle GitHub doit poster. Cliquez dessus pour la copier. Elle se termine par l’identifiant de votre projet : elle diffère pour chaque projet et n’est pas un secret — c’est la signature qui prouve l’expéditeur.

La cellule montre le chemin ; l’adresse complète est ce chemin sur https://api.snagspy.com, et c’est ce que le bouton de copie met dans le presse-papiers.

Menu latéral → Management → Integrations → la ligne de votre projet

Étape 6.5 — Où cela va sur GitHub

La carte sous le formulaire de la page Integrations le dit en une ligne, la même pour tous les dépôts : ouvrez le dépôt sur GitHub, puis Settings → Webhooks → Add webhook. Il faut être administrateur du dépôt pour voir cette page.

Menu latéral → Management → Integrations → Where to paste the URL

Étape 6.6 — Remplir le formulaire de GitHub

Quatre champs comptent. Payload URL est l’URL de livraison de l’étape 6.4. Content type doit être application/json — l’autre option envoie un encodage de formulaire sur lequel la signature n’est pas calculée. Secret est la chaîne de l’étape 6.2, exactement telle que saisie dans SnagSpy. Pour les événements, « Just the push event » suffit ; si votre pipeline utilise les Deployments de GitHub, ils sont compris aussi et ajoutent un environnement.

Cliquez sur Add webhook. GitHub envoie aussitôt une livraison ping, et SnagSpy y répond 200 — c’est ce qui passe la coche au vert sous Recent Deliveries sur la page de GitHub.

Étape 6.7 — Vérifier, et ce qui suit

Sur GitHub, l’onglet Recent Deliveries du webhook liste le ping avec une coche verte et un 200. Une croix rouge avec un 401 signifie que le secret diffère entre les deux endroits — ressaisissez-le sur GitHub, ou enregistrez-en un nouveau des deux côtés. Le corps de la réponse ne dit pas quel côté a tort, volontairement : dire à un appelant non authentifié si un projet a une intégration est une chose que nous refusons.

Le prochain push sur la branche par défaut apparaît sous Deployments dans le menu latéral en quelques secondes, et sous Releases comme le commit d’arrivée. Dès lors, chaque problème porte la version dans laquelle il est apparu.

Étape 7.1 — À quoi sert la ligne de commande

Un paquet npm, snagspy, fait trois choses : il envoie les source maps qui rendent lisible une trace de pile minifiée, il soumet un changement pour relecture, et il sert votre télémétrie à un agent de programmation via MCP. Il n’envoie pas d’erreurs — cela reste la partie 3 — et vient donc après l’arrivée d’un événement.

Il est publié et s’installe normalement ; il demande Node 20.19 ou plus récent. Il s’authentifie avec une clé d’API plutôt qu’un DSN, et la clé a une portée : celle que vous créez pour un pipeline de build peut envoyer des source maps et ne peut pas lire un seul événement.

Étape 7.2 — Créer une clé d’API à une seule portée

API Keys est sous Management. Nommez la clé d’après ce qui l’utilisera — une clé appelée « test » est une clé que personne n’osera révoquer plus tard — et ne cochez que la portée dont cette tâche a besoin. Pour envoyer des source maps, c’est Upload debug artifacts ; la carte dit en toutes lettres qu’elle ne peut ni lire vos événements ni renommer vos projets, ce qui est tout l’intérêt de la séparation.

Menu latéral → Management → API Keys → Create a key

Étape 7.3 — Copier la clé tout de suite

La clé s’affiche une fois, dans un encadré mis en évidence, avec un bouton Copy key. La plateforme en stocke un condensat : elle ne peut pas la réafficher ; si elle est perdue, révoquez-la et créez-en une autre. La liste ne montre ensuite que le préfixe, qui sert à distinguer les clés.

Menu latéral → Management → API Keys → juste après Create Key

Étape 7.4 — L’installer et vérifier qui vous êtes

La CLI lit la clé dans SNAGSPY_TOKEN. Il existe un drapeau --token qu’il vaut mieux éviter : un argument est visible par tout ce qui liste les processus, et il finit dans l’historique du shell. whoami affiche l’organisation à laquelle la clé appartient et ses portées, rien d’autre : c’est la commande à lancer quand quelque chose est refusé, et son résultat se colle sans risque dans un rapport de bug.

export SNAGSPY_TOKEN=slk_...        # la clé de l’étape 7.3
npx snagspy@0.1.3 whoami            # ou : npm install -g snagspy

Étape 7.5 — Envoyer les source maps depuis votre build

Une trace de pile minifiée nomme t.js:1:4821, ce qui ne dit rien à personne. Envoyer les maps d’une version la ramène au fichier et à la ligne que quelqu’un a écrits. Lancez ceci dans le build, après le bundler et avant le déploiement, avec l’ID DU PROJET de l’étape 2.6 et le même nom de version que celui que votre application déclare.

Passez toujours --release. Une map envoyée sans lui ne peut pas être associée au build qui a produit l’erreur, et une pile non résolue ressemble exactement à celle d’une version dont vous n’avez jamais envoyé les maps.

snagspy upload --project <ID DU PROJET> --release v1.4.2 ./dist

snagspy upload: 1 sent, 0 skipped, from ./dist

Étape 7.6 — Mettre votre télémétrie dans votre agent de programmation

snagspy mcp sert la télémétrie de votre organisation via MCP sur stdio, ce que parlent Claude Code, Cursor et les autres clients agents. L’agent qui modifie un fichier peut alors demander ce qui échoue réellement en production, au lieu que vous colliez une trace de pile dans une conversation. Même paquet, une clé avec Read events et, si vous voulez qu’il change des statuts, Triage issues.

{
  "mcpServers": {
    "snagspy": {
      "command": "npx",
      "args": ["-y", "snagspy@0.1.3", "mcp"],
      "env": { "SNAGSPY_TOKEN": "slk_..." }
    }
  }
}

Étape 8 — Inviter les personnes qui partagent l’astreinte

Teams est sous Management. Une adresse et un rôle : un membre lit la télémétrie et trie les problèmes ; un administrateur peut en plus créer des projets, émettre des DSN et envoyer des artefacts de débogage ; un propriétaire peut aussi inviter, retirer, changer les rôles, lire le journal d’audit et configurer l’authentification unique.

Les sièges sont vérifiés à l’émission de l’invitation, puis de nouveau à son acceptation. L’offre gratuite est à un siège : une deuxième personne suppose une offre payante. L’invitation est liée à l’adresse à laquelle elle a été envoyée et expire ; un lien transféré ne suffit pas pour rejoindre à sa place.

Menu latéral → Management → Teams → Invite a colleague

Étape 9.1 — Décider ce que l’IA peut lire

Settings est sous Management. L’analyse d’un problème par l’IA est un interrupteur, par organisation, et la carte dit exactement ce qu’une analyse envoie : l’exception, sa trace de pile, les décomptes et la version corrélée, jamais d’identifiants d’utilisateurs finaux ni de sacs d’attributs. L’envoi de code source pour relecture est un second interrupteur, distinct, désactivé au départ, et il ne relit que le diff qu’un pipeline poste — rien n’est récupéré dans vos dépôts, parce que la plateforme ne détient aucun identifiant qui le permettrait.

Laisser l’un ou l’autre éteint est une réponse valable, et le produit continue de fonctionner.

Menu latéral → Management → Settings → AI processing

Étape 9.2 — Vérifier combien de temps les données sont gardées

La conservation est un plafond par offre — sept jours sur l’offre gratuite pour les erreurs comme pour les traces, comme la carte le montre — que vous pouvez abaisser et non relever. Une tâche planifiée supprime réellement et le plafond est de nouveau vérifié à la lecture : c’est une vraie limite, pas un réglage d’affichage. Sept jours est volontairement trop court pour y faire tourner une astreinte ; c’est assez pour voir le produit fonctionner.

Menu latéral → Management → Settings → Data retention

À quoi ressemble une installation terminée

• Un projet existe, et sa CLÉ est dans votre environnement de déploiement plutôt que dans votre dépôt.
• Votre compteur d’événements de la période est supérieur à zéro, et vous avez vu une vraie erreur dans la liste Errors.
• Au moins une destination d’alerte existe, et la liste d’Overview s’est retirée d’elle-même.
• Un push sur votre branche par défaut apparaît sous Deployments, si vous avez connecté GitHub.
• Une clé de CI à une seule portée envoie les source maps, si vous livrez du JavaScript minifié.
• Toute personne susceptible d’être réveillée dispose d’un compte.
• Les réglages d’IA et de conservation disent ce que vous vouliez qu’ils disent, plutôt que ce qu’ils valaient par défaut.

Si quelque chose ne fonctionne pas

Les deux endpoints de santé de la page d’état répondent sans authentification : vous pouvez distinguer un problème de plateforme d’un problème de configuration avant même d’écrire à quiconque. L’étape 4.4 donne les deux commandes qui séparent les causes courantes.

Si c’est un problème de configuration, support@snagspy.com est lu par les personnes qui ont construit ceci. Indiquez le nom du projet et l’heure approximative de l’événement qui n’est pas arrivé.