"Wij horen het wel als iets stuk is." Dat is de gedachte waar veel maatwerksoftware op draait, en hij klopt niet. Gebruikers melden fouten zelden: ze proberen het nog een keer, halen hun schouders op of vertrekken. Tegen de tijd dat iemand wél belt, is de fout al dagen oud en de context weg. Daarom krijgt elke applicatie die wij bouwen error tracking mee vanaf de eerste oplevering, niet als optie achteraf.
Wat error tracking is
Error tracking betekent dat elke onafgevangen fout in je applicatie zichzelf meldt bij een centraal punt, op het moment dat hij optreedt. Niet als kale logregel, maar met alles erbij:
- De stacktrace — welke regel code, via welke aanroepen.
- De release — in welke versie van de applicatie de fout optrad, zodat je ziet of een deploy hem introduceerde.
- De context — browser of client, het verzoek dat misging, en hoeveel gebruikers het raakt.
Identieke fouten worden gegroepeerd tot één issue met een teller, en bij een nieuwe of terugkerende fout gaat er een alert uit. Dat is het wezenlijke verschil met logbestanden: in logs moet je gaan zoeken, een issue komt naar je toe. De vage klacht "het deed het gisteren even niet" heeft normaal alleen een tijdstip; met error tracking heeft dat tijdstip een stacktrace.
Waarom wij GlitchTip self-hosted draaien
Foutdata is geen neutrale data. Een stacktrace komt met request-parameters, een sessie, soms het e-mailadres van de ingelogde gebruiker. De bekende trackers zijn SaaS-diensten, veelal in de Verenigde Staten, en daar stuur je die context dus allemaal heen — een extra verwerker in je AVG-administratie voor data die je nooit als "persoonsgegevens" had bestempeld.
Wij draaien daarom GlitchTip: een open-source tracker die compatibel is met de Sentry-SDK's, op onze eigen infrastructuur. Je applicatie gebruikt de standaardbibliotheek van je taal of framework; alleen het adres wijst naar ons platform in plaats van naar een dienst overzee. De foutdata van jouw applicatie staat daarmee op dezelfde infrastructuur als de applicatie zelf, binnen de EU en binnen ons beheer. Het privacyverhaal wordt er een stuk korter van: er komt geen partij bij.
Hoe het bij onze projecten werkt
Bij oplevering is de koppeling er al: de SDK zit in de applicatie, releases worden bij elke deploy doorgegeven en alerts komen binnen op dezelfde kanalen waar ook onze infrastructuurmeldingen landen. In de praktijk verandert dat het gesprek. Zonder error tracking begint een storing met "kunt u een screenshot sturen en vertellen wat u precies deed?" Met error tracking begint hij met "we zien hem, hij zit in de release van dinsdag, dit is de oorzaak." Vaak is dat gesprek er niet eens, omdat de fout gerepareerd is voordat iemand hem meldde.
Voor wie zelf onder de NIS2-meldplicht valt is dit bovendien geen luxe: je kunt geen incident binnen 24 uur melden dat je pas na een week ziet.
Wat het niet is
Error tracking is geen monitoring. Monitoring zegt of de dienst draait: is de server bereikbaar, is er schijfruimte, reageert de site. Error tracking zegt wat er misging in de code, voor die ene gebruiker met die ene invoer, terwijl alle lampjes groen staan. Een gezonde applicatie heeft beide nodig; het een vervangt het ander niet.
Software die zichzelf meldt
Error tracking is een vast onderdeel van hoe wij software bouwen en doorontwikkelen: wat wij opleveren, kunnen we ook aantoonbaar in de gaten houden. Draait je applicatie bij ons, dan draait de foutdata mee op onze eigen cloudinfrastructuur. Wil je weten hoe dit er voor jouw applicatie uitziet, of heb je nu een applicatie waarvan niemand weet of hij fouten geeft: neem contact op.