Alternatives à Sentry qui ne ruineront pas votre side project quand il scale

Pourquoi les fondateurs cherchent des alternatives à Sentry

Sentry est un excellent logiciel. Les SDKs couvrent chaque langage et chaque framework. Le groupement d'erreurs est intelligent. Le workflow de debug — stack trace, breadcrumbs, tags, contexte de release — est vraiment le meilleur de la catégorie. Si on fait tourner une app en production avec des clients payants, Sentry aide à trouver et corriger les bugs plus vite que n'importe quel autre outil de cette liste.

Alors pourquoi chercher ailleurs ?

La tarification qui scale mal. Le plan gratuit Developer de Sentry plafonne à 5 000 erreurs par mois. Le plan Team démarre à 26 $/mois pour 50K erreurs. Le plan Business à 80 $/mois pour 100K. Ces chiffres semblent généreux jusqu'au jour où on shippe un bug en production qui lance une exception sur chaque page view. Un seul mauvais deploy peut cramer le quota mensuel en quelques heures. Et une fois le cap atteint, Sentry arrête d'ingérer — on devient aveugle exactement au moment où on a le plus besoin de visibilité.

L'angoisse du quota d'events. Le modèle de tarification par event crée une incitation perverse : on se met à stresser sur le coût de ses propres bugs. Est-ce qu'on ajoute l'error tracking à cette nouvelle feature ? Et si c'est bruyant pendant le développement ? Les fondateurs solo et les petites équipes rapportent passer plus de temps à configurer des rate limits et des règles de sampling qu'à réellement débugger. Ce overhead va à l'encontre de l'intérêt d'avoir de l'error tracking.

Trop de complexité pour les petites équipes. Sentry est devenu une plateforme d'observabilité complète — error tracking, performance monitoring, profiling, session replay, cron monitoring, et plus encore. Pour une équipe de 50 devs, cette consolidation a de la valeur. Pour un fondateur solo avec une app, le dashboard est overwhelming et la plupart des features restent inutilisées. On paie un cockpit enterprise quand on a juste besoin d'un voyant "check engine".

Le self-hosting est devenu lourd. Sentry était la référence en error tracking auto-hébergé. L'édition open source existe toujours, mais la faire tourner nécessite une infrastructure conséquente — Kafka, ClickHouse, PostgreSQL, Redis et plusieurs services. Ce n'est plus quelque chose qu'on déploie tranquillement sur un VPS à 5 $. Ca a ouvert la porte à des alternatives plus légères comme GlitchTip.

Pour les fondateurs bootstrapés qui surveillent leur burn rate, les maths comptent. Une facture d'error tracking de 26-80 $/mois, c'est 312-960 $/an. Si un outil plus simple à 0-10 $/mois donne 80 % de la fonctionnalité, c'est de l'argent réel qui revient dans le runway.

Analyse détaillée : ce que chaque alternative fait de mieux

BetterStack — l'ops unifié dans un seul dashboard

BetterStack est né de la fusion de Better Uptime (uptime monitoring) et Logtail (log management) en une seule plateforme. Le résultat : un outil d'ops qui couvre l'uptime monitoring, le log management structuré et l'alerting d'incidents au même endroit.

L'approche de l'error tracking est différente de Sentry. Au lieu de drop un SDK dans l'app qui catch les exceptions, on envoie des logs structurés à BetterStack et on configure des alertes sur les events de niveau erreur. Ca signifie qu'on a le contexte complet autour de chaque erreur — pas juste une stack trace, mais la requête qui l'a causée, les requêtes base de données qui ont tourné avant, et l'état de l'application à ce moment-là.

Le free tier inclut 10 uptime monitors et 1 Go de stockage de logs. Pour une petite app avec du structured logging déjà en place, ça couvre la visibilité de base sur les erreurs. Le plan Plus à 25 $/mois augmente le stockage de logs et ajoute des fonctionnalités d'équipe.

Les pages de statut d'incidents sont un bonus appréciable. Si l'app tombe et qu'on a besoin de communiquer avec les utilisateurs, BetterStack fournit une page de statut hébergée sur tous les plans. C'est un outil que la plupart des fondateurs bricolent séparément.

La limitation, c'est que BetterStack n'est pas un remplacement drop-in de Sentry. Il n'y a pas de BetterStack.init() qui capture automatiquement les uncaught exceptions. Il faut du structured logging dans l'application, et la visibilité sur les erreurs dépend directement de la qualité des logs. Pour les développeurs qui pensent déjà en logs structurés, c'est naturel. Pour ceux habitués à l'instrumentation automatique de Sentry, c'est plus de travail au départ.

Quand choisir BetterStack : On veut uptime monitoring, log management et alerting sur les erreurs dans un seul outil. Particulièrement pertinent si on paie actuellement pour des services séparés d'uptime, de logs et d'error tracking.

Highlight.io — l'open source avec session replay

Highlight.io est ce qui se rapproche le plus d'une alternative open source moderne à Sentry, avec un twist : le session replay est une fonctionnalité de premier plan, pas un ajout après coup. Quand une erreur se produit, on peut regarder la session exacte où ça s'est passé — ce que l'utilisateur a cliqué, ce qu'il a vu, et ce qui a merdé.

L'error tracking en lui-même est solide. Des SDKs pour Next.js, React, Python, Go, Ruby et Java. Support des sourcemaps pour des stack traces lisibles. Groupement et déduplication d'erreurs. Alerting via Slack, email ou webhooks. Les fondamentaux sont couverts.

Ce qui fait la différence de Highlight.io, c'est le workflow de debug. On clique sur une erreur, on regarde le session replay, on voit les requêtes réseau et les console logs de cette session. Pour les bugs frontend qui dépendent de l'état utilisateur ou de séquences d'interactions, c'est drastiquement plus utile qu'une stack trace seule. Sentry a ajouté le session replay aussi, mais Highlight.io a été construit autour de cette idée depuis le premier jour.

Le free tier est serré : 500 sessions, 1 000 erreurs et 1 million de lignes de log par mois. Une petite app avec quelques centaines d'utilisateurs quotidiens va taper ces limites en quelques semaines. La tarification usage-based après le free tier atterrit typiquement autour de 20 $/mois pour une petite app indie, et scale avec le volume.

Le self-hosting est possible via Docker mais nécessite ClickHouse pour le backend de données, qui est gourmand en ressources. Il faut prévoir au minimum un serveur avec 4 Go de RAM, ce qui porte le coût réaliste du self-hosting à 15-20 $/mois d'infrastructure.

Quand choisir Highlight.io : On build des apps web et on veut voir ce que les utilisateurs ont vécu quand les erreurs se sont produites. L'intégration du session replay est le killer feature.

Bugsnag — le champion du signal-to-noise

Bugsnag fait une chose exceptionnellement bien : le groupement d'erreurs. Quand l'app throw la même erreur 10 000 fois à cause d'un bug dans un chemin de code critique, Bugsnag montre un seul problème avec un compteur de 10 000 — pas 10 000 alertes séparées. Ca semble basique, mais la qualité de l'algorithme de groupement fait une vraie différence en pratique.

Le groupement utilise une combinaison d'analyse de stack trace, de patterns de messages d'erreur et de contexte de code pour regrouper les erreurs liées. Sentry fait ça aussi, mais le groupement de Bugsnag est plus agressif pour fusionner les variantes d'un même bug sous-jacent. Le résultat : une inbox d'erreurs plus propre où chaque entrée représente un problème distinct à investiguer.

Le release tracking est un autre point fort. Chaque deploy est tagué, et Bugsnag montre quelles erreurs sont nouvelles dans chaque release, lesquelles sont des régressions de releases précédentes, et les tendances de stabilité globale. Pour un fondateur solo qui shippe plusieurs fois par jour, c'est le moyen le plus rapide de détecter quand un deploy casse quelque chose.

Le free tier donne 7 500 events par mois sur un seul projet. Le plan Team à 47 $/mois passe à 25K events et ajoute les projets multiples. Pour un indie builder avec un frontend et un backend, la limitation à un seul projet sur le free tier est frustrante — il faut choisir quel codebase monitorer.

Le support mobile, c'est là où Bugsnag a fait sa réputation. Les SDKs iOS, Android, React Native, Flutter et Unity sont tous matures et bien documentés. Si on build une app mobile, le crash reporting de Bugsnag est sans doute meilleur que celui de Sentry en termes de qualité de symbolication et de groupement de crashs.

Quand choisir Bugsnag : On veut l'inbox d'erreurs la plus propre avec un minimum de configuration. Particulièrement fort pour les apps mobiles ou tout projet où le bruit des erreurs est un vrai problème.

GlitchTip — le Sentry auto-hébergé au prix d'un VPS

GlitchTip est le choix pragmatique pour les fondateurs qui veulent de l'error tracking style Sentry sans la tarification style Sentry. C'est wire-compatible avec les SDKs Sentry, ce qui signifie qu'on installe la librairie client Sentry officielle dans l'app et on la pointe vers son serveur GlitchTip. L'instrumentation Sentry existante fonctionne sans modification.

Le self-hosting avec Docker Compose est straightforward. GlitchTip tourne sur PostgreSQL (pas de ClickHouse, pas de Kafka), ce qui veut dire que ça tient confortablement sur un VPS à 5-10 $/mois. L'empreinte ressource est une fraction de celle de Sentry auto-hébergé. Un serveur de 1 Go de RAM gère une petite à moyenne application sans problème.

Le jeu de fonctionnalités est volontairement minimal. On a l'error tracking avec stack traces, breadcrumbs, tags et contexte utilisateur. On a le groupement d'erreurs et l'alerting. On a un uptime monitoring basique. On n'a pas le performance monitoring, le session replay, le profiling ni le cron monitoring. Pour beaucoup de fondateurs indie, c'est exactement le bon set de features — les trucs qu'on regarde au quotidien, sans le surplus de dashboard.

Les plans hébergés démarrent à 4 $/mois pour 1 000 events, jusqu'à 42 $/mois pour 100K events. L'option self-hosted n'a aucune limite d'events — on est contraint uniquement par l'espace disque du serveur et les performances de la base de données.

Le compromis, c'est la vélocité de développement. GlitchTip a une petite équipe, donc les nouvelles fonctionnalités et les bug fixes arrivent plus lentement que chez Sentry. L'UI est fonctionnelle mais pas léchée. Si l'expérience de debug de Sentry est un 9/10, GlitchTip est un 6 — suffisant pour la plupart du debug, mais on regrette occasionnellement le polish.

Quand choisir GlitchTip : On veut l'error tracking le moins cher possible, compatible avec les SDKs Sentry. Idéal pour les auto-hébergeurs qui veulent des erreurs illimitées à un coût d'infrastructure fixe.

PostHog — les erreurs dans l'analytics

L'error tracking de PostHog est le dernier arrivé dans cette catégorie, et le pitch c'est l'intégration plutôt que la spécialisation. Comme PostHog track déjà les sessions utilisateurs, les évaluations de feature flags et les product events, ajouter l'error tracking signifie que chaque crash arrive avec le contexte utilisateur complet automatiquement.

Le bénéfice concret, c'est le workflow de debug. Une erreur dans PostHog n'est pas juste une stack trace — c'est une stack trace attachée à une session utilisateur, avec le session replay, les feature flags actifs, et les product events qui ont mené à l'erreur. Si on utilise déjà PostHog pour le product analytics, ce contexte est gratuit.

Le free tier inclut 1 million d'error events par mois. C'est le free tier managé le plus généreux de cette catégorie, et de loin. Pour une petite à moyenne app indie, on ne paiera peut-être jamais pour l'error tracking.

La limitation, c'est la maturité. L'error tracking de PostHog a été lancé récemment et n'atteint pas la profondeur de Sentry en groupement d'erreurs, corrélation de performances ou gestion de releases. L'expérience stack trace est fonctionnelle mais pas aussi peaufinée. Si l'error tracking est le besoin principal et qu'on n'utilise pas PostHog pour le reste, un outil dédié est un meilleur choix.

Quand choisir PostHog : On utilise déjà PostHog pour l'analytics ou le session replay et on veut consolider l'error tracking dans la même plateforme.

Axiom — l'error tracking pour les développeurs natifs du log

Axiom est une plateforme de log management avec un free tier tellement généreux qu'on se demande si c'est une erreur. 500 Go d'ingest de logs par mois, 30 jours de rétention, sur le plan gratuit. Si l'application émet des logs structurés (et elle devrait), Axiom peut servir de système d'error tracking.

Le workflow : on structure les logs de l'application avec les niveaux d'erreur, les stack traces et les metadata. On les envoie à Axiom. On crée un dashboard qui filtre les events de niveau erreur. On configure des alertes pour les nouveaux patterns d'erreurs. On a maintenant de l'error tracking.

La puissance de requête, c'est là où Axiom brille. APL (Axiom Processing Language) permet de découper les données d'erreur par n'importe quelle dimension — endpoint, utilisateur, version de release, durée de requête, région géographique. Des requêtes de debug complexes qui nécessiteraient du tooling custom dans Sentry sont juste des requêtes dans Axiom.

L'intégration Vercel est particulièrement fluide. Si l'app tourne sur Vercel, Axiom peut ingérer les logs de fonctions automatiquement. Combiné avec des error boundaries Next.js qui émettent des logs structurés, on a de l'error tracking avec quasiment zéro setup.

La limitation est la même que BetterStack : ce n'est pas un SDK d'error tracking traditionnel. Il n'y a pas de capture automatique d'exceptions, pas de traitement de sourcemaps, pas de groupement d'erreurs par défaut. On construit ces capacités via du structured logging et des requêtes Axiom. Pour les développeurs qui ont déjà de bonnes pratiques de logging, c'est naturel. Pour ceux qui veulent un one-liner Sentry.init(), c'est plus de travail.

Quand choisir Axiom : On a déjà du structured logging et on veut construire de l'error tracking par-dessus. Le free tier rend ça essentiellement gratuit pour la plupart des apps indie.

Comparatif de coûts selon le volume d'erreurs

Voici ce qu'on paie réellement à différentes échelles de volume d'erreurs. Ce sont des coûts mensuels pour les plans managés/hébergés :

A 5K erreurs/mois (pré-lancement ou très petite app) :

• Sentry : Gratuit (plan Developer)
• BetterStack : Gratuit (dans la limite de 1 Go de logs)
• Highlight.io : Gratuit (dans la limite de 1K erreurs)
• Bugsnag : Gratuit (dans la limite de 7.5K)
• GlitchTip self-hosted : 5-10 $/mois (coût du VPS)
• PostHog : Gratuit (largement dans la limite de 1M)
• Axiom : Gratuit (largement dans la limite de 500 Go)

A 50K erreurs/mois (app en croissance avec de vrais utilisateurs) :

• Sentry : 26 $/mois (plan Team)
• BetterStack : 25 $/mois (plan Plus)
• Highlight.io : ~20-30 $/mois (usage-based)
• Bugsnag : 47 $/mois (plan Team, limite 25K — Business à 119 $ pour 100K)
• GlitchTip self-hosted : 5-10 $/mois (coût du VPS, pas de limite d'events)
• PostHog : Gratuit (dans la limite de 1M)
• Axiom : Gratuit (dans la limite de 500 Go)

A 500K erreurs/mois (app qui scale ou logging d'erreurs bruyant) :

• Sentry : 80+ $/mois (plan Business, avec dépassements)
• BetterStack : 85+ $/mois (plan Team avec dépassements de logs)
• Highlight.io : ~100-150 $/mois (usage-based)
• Bugsnag : Tarification enterprise sur devis
• GlitchTip self-hosted : 10-20 $/mois (VPS plus gros pour le stockage)
• PostHog : Gratuit pour le premier million, puis usage-based
• Axiom : Gratuit (500 Go est une quantité énorme de données d'erreur)

Le pattern est clair : GlitchTip auto-hébergé et les outils basés sur les logs (Axiom, BetterStack) ont les courbes de coût les plus plates. Les outils basés sur les SDKs (Sentry, Highlight.io, Bugsnag) facturent par event et les coûts scalent linéairement avec le volume d'erreurs.

Quand rester sur Sentry

Sentry reste le bon choix si :

• On a une architecture multi-services complexe où les erreurs cascadent entre services. Le distributed tracing et le performance monitoring de Sentry connectent les points entre les couches du stack d'une manière que les outils plus simples ne peuvent pas.
• Le workflow de debug dépend de fonctionnalités spécifiques à Sentry comme les code mappings, les suspect commits, le release health et le profiling. Migrer signifie perdre cette expérience de debug intégrée.
• L'équipe connaît déjà Sentry et le coût du context-switching vers un nouvel outil est plus élevé que la différence de prix. Le temps développeur a un coût aussi.
• On a besoin de certifications de conformité (SOC2, HIPAA). Le plan enterprise de Sentry les inclut. La plupart des alternatives de cette liste non.
• L'error tracking est mission-critical pour le business — la fiabilité du produit drive directement le revenu, et la différence de vitesse de debug entre Sentry et les alternatives moins chères se traduit en argent réel via une résolution d'incidents plus rapide.

Le free tier de Sentry à 5K erreurs par mois est réellement utilisable pour les produits pré-lancement et early-stage. Pas besoin de migrer préventivement. On commence avec Sentry gratuit, et on switch quand la tarification devient un problème — pas avant.

Conseils pratiques pour la migration

1. Commencer par l'environnement le moins critique. Migrer l'error tracking du staging ou du développement d'abord. Se familiariser avec l'alerting, le groupement et l'expérience de debug du nouvel outil avant de toucher à la production.

2. Pour migrer vers GlitchTip, c'est presque trivial. On garde le SDK Sentry, on change le DSN pour pointer vers l'instance GlitchTip. On teste que les erreurs apparaissent, que les stack traces se résolvent et que les alertes se déclenchent. La wire-compatibilité rend ce chemin de migration le plus simple.

3. Pour les outils basés sur les logs (Axiom, BetterStack), investir d'abord dans le structured logging. Ajouter du structured logging à l'application avec des champs cohérents : niveau d'erreur, type d'erreur, stack trace, user ID, request ID, version de release. Une fois les logs propres, l'outil vers lequel on les envoie n'a presque pas d'importance.

4. Faire tourner les outils en parallèle pendant la migration. Envoyer les erreurs à la fois à Sentry et au nouvel outil pendant 2-4 semaines. Comparer le groupement d'erreurs, la latence d'alerting et l'expérience de debug côte à côte. Ca coûte quelques dollars en events dupliqués mais évite de migrer vers un outil qui ne marche pas pour le use case.

5. Configurer le sampling côté client avant de migrer. La plupart des SDKs Sentry supportent les options tracesSampleRate et sampleRate. Régler le sampling d'erreurs pour correspondre au quota du nouvel outil. Ca empêche les dépassements de quota pendant la migration quand on calibre encore le volume.

6. Garder le DSN Sentry dans une variable d'environnement. Si le nouvel outil ne fait pas l'affaire, revenir en arrière est un changement de config, pas un changement de code. Bonne pratique quel que soit l'outil utilisé.

7. Documenter les règles d'alerting. Avant de migrer, capturer ou exporter les configurations d'alertes Sentry, les règles d'assignment des issues et les paramètres de notification. Recréer tout ça dans un nouvel outil est la partie la plus fastidieuse de la migration, et celle qu'on oublie le plus facilement jusqu'à ce que quelque chose casse en silence.