GlitchTip
Suivi d'erreurs libre, compatible avec les SDK Sentry officiels. Tu changes le DSN dans ton application et les erreurs arrivent sur ton propre serveur, sans toucher une ligne de code. Licence MIT, installation en Docker Compose avec PostgreSQL.
Forces
- Migration sans réécriture : les SDK Sentry officiels envoient vers GlitchTip tels quels, il n'y a que le DSN à changer
- Quatre composants à faire tourner (application, workers, PostgreSQL, cache optionnel), contre une pile bien plus lourde côté Sentry auto-hébergé
- Empreinte serveur minuscule : la documentation annonce 512 Mo de mémoire recommandés, ça tient sur le VPS que tu as déjà
- Licence MIT et volume illimité en auto-hébergé : le coût cesse d'être indexé sur le nombre d'erreurs que ton application produit
Limites
- Tu deviens responsable d'un service qui garde tes traces de production : sauvegardes PostgreSQL, correctifs de sécurité, disponibilité. Le jour où il tombe, tu es aveugle sur ta prod
- Périmètre volontairement plus étroit que Sentry : le Session Replay ne figure pas dans la documentation, et le confort de triage est en retrait
- Montées de version majeures annuelles avec ruptures possibles : il faut lire les notes de version avant de tirer la nouvelle image, sinon la migration de base casse
- Projet porté par une petite équipe : si le besoin devient critique pour l'entreprise, il n'y a pas de contrat de support à activer derrière
Pour qui
- Applications bavardes en erreurs, où la facturation à l'événement chez Sentry devient absurde au regard de la valeur du signal
- Contextes où les traces de production ne peuvent pas sortir du périmètre, pour des raisons réglementaires ou contractuelles
- Équipes qui gèrent déjà un serveur et un PostgreSQL : le coût marginal d'un composant de plus est faible pour elles