Je app staat live. Dan komt de vraag die vooraf zelden gesteld wordt: hoe kom je erachter dat er iets kapot is voordat een gebruiker je erop wijst? Sentry is het gereedschap waar de meeste bouwers voor die vraag op uitkomen. Hieronder wat het doet, hoe je het zonder developer inbouwt, hoe je voorkomt dat je in meldingen verzuipt, en het punt dat het vaakst wordt overgeslagen: er kunnen persoonsgegevens in je foutmeldingen zitten.
Geen bezoekersstatistiek. Een postbus voor alles wat er in je code omvalt.
Sentry is foutmonitoring, gemaakt door Functional Software, Inc., dat handelt onder de naam Sentry (sentry.io). Je zet een klein pakket in je app, de SDK. Gaat er iets mis, dan stuurt dat de fout naar Sentry en krijg jij bericht. In die melding zit de stacktrace, dus welk bestand en welke regel het lieten afweten, plus de release, het apparaat, de browser en de klikken die eraan voorafgingen. Met gebruikersinformatie aan staat er ook bij wie het overkwam. Gelijksoortige fouten worden gebundeld in een issue met een teller, zodat je ziet of iets eenmalig was of duizend keer gebeurde.
Trek dit eerst uit elkaar van iets anders, want daar gaat het bij prototypes vaak mis. Hoeveel mensen je app openen, welke stap ze niet afmaken en welke knop niemand aanraakt: dat is een ander vraagstuk, en daarvoor staat meten of je app gebruikt wordt klaar. Sentry gaat over het omgekeerde moment, dat waarop iets niet werkt. Een app kan prima gebruikt worden en tegelijk voor een deel van je mensen stuk zijn, en dat zie je in gebruiksdata niet of veel te laat.
Sentry is inmiddels breder dan foutmeldingen alleen. Er zit tracing en profiling in voor traagheid, session replay om terug te kijken wat een gebruiker deed voordat het misging, structured logs, release health met sessies en een percentage sessies zonder crash per versie, en losse uptime- en cron-monitors. Ook zit er een AI-agent in, Seer, die een oorzaak voorstelt en op verzoek een pull request opent met een poging tot fix. Die is optioneel en per organisatie uit te zetten.
Volledige openheid: wij verkopen bij OneDayBuild prototype-dagen en werken dagelijks met AI-codetools. Deze review is geschreven vanuit dat werk, niet als onafhankelijke testbank. We hebben geen commerciële band met Functional Software of Sentry.
Foutmonitoring werkt pas als er iets draait waar echte mensen op zitten.
De waarde zit niet in het horen dat iets stuk is. Die zit in wat er in de melding staat.
Met de klacht dat hij niks doet kan niemand iets. Met een Sentry-issue wel: je ziet welke regel in welk bestand omviel, in welke release, op welk apparaat en in welke browser, met de klikken en netwerkverzoeken ervoor als spoor. Zet je gebruikersinformatie aan, dan zie je ook wie het raakte en hoeveel mensen erdoor geraakt zijn.
Bij code die je met AI hebt laten schrijven weet je vaak niet precies wat er in de randgevallen gebeurt. Sentry lost dat niet op, maar het maakt de gaten zichtbaar op het moment dat ze geraakt worden. Hoe je daarna met die code omgaat, staat in AI-gegenereerde code onderhouden.
Voor veel frameworks is er een installatiescript, de Sentry-wizard, dat het pakket toevoegt, de configuratiebestanden aanmaakt en je project- en sleutelgegevens invult. Voor een gewone website blijft het bij een paar regels. Wie zelf niets in de code kan, kan dit als losse opdracht laten doen: een eenmalige ingreep, geen doorlopend project.
Twee dingen gaan bij bijna iedereen mis: te veel meldingen en te veel gegevens.
Zelf hosten kan, en soms heb je Sentry helemaal nog niet nodig.
Je kunt Sentry op je eigen server zetten. De code staat onder de Functional Source License, een variant op de Business Source License: vrij te gebruiken, aan te passen en te verspreiden, met als grens dat je er geen concurrerend aanbod van maakt, en elke release wordt na twee jaar Apache 2.0. De installatie loopt via Docker Compose met een installatiescript. Reken wel op een stevige machine, want de minimumeisen liggen boven die van een kleine VPS, en Sentry levert die variant zonder garanties en zonder toegezegde ondersteuning: je valt terug op de community. Een aantal onderdelen ontbreekt er ook in. Zelf hosten is dus een keuze voor wie de gegevens per se in eigen beheer wil, en je betaalt die keuze in beheerstijd.
Heb je minder nodig, dan levert je hostingplatform vaak al iets. Logs en runtime-fouten staan bij de meeste partijen in het dashboard, maar ongegroepeerd, zonder alert en zonder versie, dus je moet er zelf gaan kijken. Voor een prototype dat nog niet in de lucht hoeft te blijven is dat genoeg; de afweging staat in prototype hosten na de bouwdag. Er is ook een lichter open alternatief, GlitchTip, dat op de Sentry-SDK's aansluit zodat je dezelfde pakketten in je app kunt laten zitten.
Blijf ten slotte scherp op het onderscheid dat het vaakst door elkaar loopt. Foutmonitoring vertelt je dat iets kapot is en waar. Gebruiksmeting vertelt je of iemand het daadwerkelijk gebruikte; daarvoor is meten of je app gebruikt wordt het startpunt. Beide worden pas echt bruikbaar zodra je ze aan versies hangt, want dan zie je na een release of het beter of slechter werd. Hoe je dat inricht staat in updates uitbrengen na je lancering.
Geen cijfer. Wel een duidelijk moment waarop je dit aanzet.
Staat je app live en gebruiken echte mensen hem, dan is foutmonitoring geen extraatje maar het minimum. Sentry is daarin de breedst ondersteunde optie: er is een pakket voor vrijwel elke taal en elk framework, de melding bevat wat je nodig hebt om een probleem te plaatsen, en het gratis niveau is genoeg om te zien of het je iets brengt. Zet het aan op de dag dat je live gaat, niet op de dag dat de eerste klant belt.
Twee dingen moet je meteen goed doen, anders werkt het tegen je. Knijp je alerts dicht tot wat je echt wilt weten, want een alarm dat niemand meer opent is geen alarm. En bepaal voordat je live gaat welke gegevens je meestuurt, kies bewust je regio en regel de verwerkersovereenkomst. Doe je dat laatste niet, dan maak je een tweede plek waar persoonsgegevens van je gebruikers staan zonder dat iemand dat heeft opgeschreven, en dat is precies het soort ding dat later duur uitvalt.
Bij OneDayBuild komt deze vraag vooral op zodra er iets staat. Wil je eerst in een werkdag van idee naar een klikbaar prototype, dan kijken we in een intake mee welke flow je wilt testen. Twijfel je of jouw idee klein genoeg is voor zo'n dag, loop dan de kan-dit-in-1-dag-check na.
Sentry is foutmonitoring. Je zet een klein pakket in je app en zodra er iets omvalt, stuurt dat pakket de fout op: de stacktrace met het bestand en de regel, de release waarin het gebeurde, browser en apparaat, en de klikken die eraan voorafgingen. Gelijksoortige fouten worden gebundeld in een issue met een teller, zodat je ziet of iets eenmalig is of structureel.
Bezoekersstatistieken vertellen je of iemand je app gebruikt en waar hij afhaakt. Sentry vertelt je dat iets niet werkt en waarom. Een app kan prima gebruikt worden en tegelijk voor een deel van je mensen stuk zijn, dus de twee vervangen elkaar niet. Je hebt ze naast elkaar nodig.
Ja. De code staat onder de Functional Source License, een variant op de Business Source License: vrij te gebruiken en aan te passen, met als grens dat je er geen concurrerend aanbod van maakt, en elke release wordt na twee jaar Apache 2.0. Installeren gaat via Docker Compose met een installatiescript. Sentry levert die variant zonder garanties en zonder toegezegde ondersteuning, en een aantal onderdelen ontbreekt erin.
Dat kan. Sentry biedt opslag in de Verenigde Staten en in de EU, met een eigen domein per regio. Voor een bestaande organisatie op de gehoste dienst is die keuze niet meer te wijzigen: dan zou je een nieuwe organisatie moeten aanmaken. Kies dus bij het aanmaken, niet later.
Sentry stuurt persoonsgegevens niet standaard mee. In de JavaScript-SDK regelde de optie sendDefaultPii dat, met false als standaard; die is inmiddels als verouderd gemarkeerd ten gunste van een fijnmaziger dataCollection-instelling waarmee je per categorie kiest. Wil je harder filteren, dan haal je velden weg met een beforeSend-hook voordat er iets verstuurd wordt, of je zet scrubbing-regels in de Sentry-interface zodat het daar niet wordt opgeslagen. Wie het helemaal buiten de deur wil houden, zet een eigen Relay tussen de app en Sentry.
Niet noodzakelijk voor de installatie. Voor veel frameworks is er een installatiescript dat het pakket toevoegt, de configuratiebestanden aanmaakt en je projectgegevens invult; voor een gewone website is het een paar regels. Voor het beoordelen van wat er in een melding staat heb je wel iemand nodig die een stacktrace kan lezen.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in een werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.