De meeste storingen worden gemeld door de persoon die er last van heeft, en dat is altijd later dan het moment waarop ze begon. Wat ertussen zit is geen geluk maar een keuze: wat je meet, wanneer je het te horen krijgt, en met hoeveel context erbij.
Er zijn drie soorten vragen, en ze vragen alle drie iets anders. De eerste is of er iets kapot is: een uitzondering, een verzoek dat een foutcode teruggeeft, een taak die niet afraakt. De tweede is of er iets traag geworden is, wat lastiger is omdat er niets faalt en de klacht vaag blijft. De derde is of er iemand langskwam, en wat die dan deed.
De eerste twee horen bij elkaar en komen uit de applicatie zelf: fouten, logboeken en traces. De derde is iets anders van aard en hoort thuis bij bezoekcijfers. Dat lijkt een detail, maar het bepaalt waar je je gegevens laat: een bezoekersteller weet wie je klanten zijn, een foutenverzamelaar weet wat er in je applicatie gebeurt. Geen van beide hoef je uit handen te geven.
Zes stukken tussen een fout die optreedt en iemand die er iets mee doet.
Bugtail verzamelt fouten, logs en traces van meerdere applicaties en bundelt ze tot issues die je kan oplossen in plaats van een stroom losse meldingen. Self-hosted, dus de stack traces van je klanten blijven op je eigen server.
Bugtail spreekt de Sentry- en OpenTelemetry-sdk's. Overstappen is daarmee een adres veranderen en geen herschrijving, en je zit niet vast: dezelfde code werkt ook bij een andere ontvanger.
Meldingen worden op hun vingerafdruk samengelegd tot een issue met een teller. Een storing die duizend keer optreedt is dan een regel die duizend zegt, en geen inbox die dichtslibt op het moment dat je het overzicht het hardst nodig hebt.
Matomo op een eigen adres in plaats van een script dat je bezoekers meeneemt naar een advertentiemarkt. Je ziet wat je nodig hebt, je bezoeker wordt geen product, en je verwerkersregister blijft kort.
Een webhook naar Slack of Teams wanneer er iets misloopt, met genoeg context om te weten of het kan wachten. Wie een meldingsmail moet openen om te zien dat het niets was, leest ze na een week niet meer.
Wat bij de klantendienst binnenkomt en een bug blijkt, wordt een issue in Jira met de gegevens van het geval erbij, en de status komt langs een webhook terug. Zo hoeft niemand te gaan vragen hoe ver het staat.
Vijf keuzes die bepalen of een meldingskanaal na een maand nog gelezen wordt.
Dat er een fout was, is de minst nuttige helft. Welke gebruiker, welke pagina, welke invoer, welke versie, welk toestel: dat is wat het verschil maakt tussen tien minuten en een halve dag. Die context verzamel je bij het optreden, want achteraf reconstrueren lukt niet.
Wat je verzamelt gaat langs een wachtrij en niet langs het verzoek van de bezoeker. Ligt de ontvanger eruit, dan hoort je applicatie gewoon door te draaien. Een meetsysteem dat je site kan platleggen is een risico dat je erbij kocht in plaats van er een weg te nemen.
In een stack trace staat geregeld een mailadres, een adres of een volledig verzoek met een token erin. Dat filter zet je aan de kant van de applicatie, voor het vertrekt, en niet aan de kant van de ontvanger. Anders is je foutenlogboek een gegevensverzameling geworden zonder dat iemand dat besliste.
Een meldingsregel die twintig keer per week afgaat, wordt na twee weken weggeklikt. Beter minder melden en die meldingen serieus nemen. Wat je wil weten maar niet wakker hoeft te maken, hoort in een overzicht dat je een keer per dag bekijkt.
Een uitzondering is makkelijk: er staat een regelnummer bij. Lastig is de pagina die traag geworden is zonder dat er iets faalt. Daar heb je traces voor nodig, met de tijd per stap, en die zet je best op voor je ze nodig hebt. Achteraf aanzetten betekent wachten tot het zich opnieuw voordoet.
Dan valt er doorgaans met een halve dag werk al veel te winnen: de sdk erin, een kanaal eraan, en een drempel die laag genoeg staat om iets te vangen en hoog genoeg om gelezen te blijven. Stuur gerust een bericht.
Bugtail staat op bugtail.eu, de helpdeskkant bij de FreeScout-koppeling, de weg naar de ontwikkelaars bij Jira, en wat je doet als het echt fout gaat bij continuiteit en herstel.