bvdart-health · Eigen project
Eén dashboard voor vier sites — bvdart-health
Eén dashboard dat vier eigen sites volgde op vindbaarheid, snelheid, fouten en kosten, met elke ochtend om acht uur één bericht over wat aandacht vroeg. Gebouwd in juni 2026 en inmiddels uitgezet.
Van dit project is geen beeld beschikbaar. De case beschrijft de werking en de uitkomsten.
- Soort project
- Eigen project
- Mijn rol
- Ontwerp en ontwikkeling van de monitoring
- Status
- Afgerond · systeem uitgezet
- Doorlooptijd
- 2 dagen
- Teamgrootte
- 1
- De vraag
- Signalen over snelheid, vindbaarheid, kosten en fouten stonden verspreid over verschillende dashboards.
- Het resultaat
- Eén dagelijks bericht bundelde de aandachtspunten van vier sites. Het systeem is inmiddels uitgezet.
De vraag
Dit is geen klantopdracht maar eigen gereedschap. Vier sites tegelijk in de lucht houden betekende dat de antwoorden op simpele vragen — wordt dit nog gevonden, is het nog snel, kost het niet ineens geld, gaat er iets stuk — verspreid stonden over zes dashboards van zes leveranciers. Daarna kwam er elke ochtend om acht uur één bericht: dit vraagt aandacht, of alles zit binnen de grenzen. Zolang het draaide, maakte het meermaals een klein foutje zichtbaar dat anders geld had gekost. Het systeem staat inmiddels uit.
Vier sites, elk met een eigen verzameling meetpunten bij een eigen leverancier. Vindbaarheid staat in Search Console. Snelheid moet je meten. Kosten staan in vier losse facturen met vier verschillende gratis tegoeden. Fouten staan weer ergens anders.
Zolang alles goed gaat, kijk je daar niet naar. Precies daarom merk je het niet als het misgaat: een gratis tegoed dat volloopt, een pagina die na een wijziging trager werd, een foutmelding die zich sinds gisteren herhaalt. Niet één daarvan is dramatisch. Bij elkaar zijn het de dingen die je pas ontdekt als iemand anders er last van heeft. Wat ik nodig had was niet méér informatie, maar minder: één oordeel per dag.
Kernproblemen
- Meetpunten verspreid over zes dashboards van zes verschillende leveranciers
- Verbruik dat ongemerkt oploopt tot het op de rekening staat
- Snelheidsverlies na een wijziging valt pas op als een bezoeker klaagt
- Geen enkele reden om dagelijks te gaan kijken zolang alles goed lijkt te gaan
Randvoorwaarden
- Het meetsysteem mag niet afhankelijk zijn van de systemen die het bewaakt
- Alleen leesrechten op de gemonitorde omgevingen
- Moest binnen een paar dagen bruikbaar zijn, niet na een project van weken
Achtergrond van het project
Dit is eigen werk, en dat zeg ik erbij. Er zit geen klant achter die tevreden was — wat het laat zien is hoe ik werk als niemand meekijkt, en welk gereedschap ik voor mezelf bouw als iets me te vaak stoort.
Mijn aanpak en keuzes
Het systeem mag niet meevallen met wat het bewaakt. Het draait in een eigen omgeving, losgekoppeld van de sites die het volgt, en het heeft alleen leesrechten. Valt er iets om, dan valt het meetsysteem er niet mee om — anders weet je het juist op het slechtste moment niet.
Eén oordeel per dag, geen scherm om in de gaten te houden. Elke ochtend om acht uur kwam er één bericht binnen: wat een grens overschreed, of de bevestiging dat alles erbinnen bleef. Een dashboard dat je moet openen om te weten of je het moet openen, lost niets op.
De grenzen staan op één plek. Wat ‘te traag’ of ‘te duur’ is, ligt server-side vast — één definitie die zowel het ochtendbericht als het dashboard voedt. Anders krijg je precies het probleem dat je wilde oplossen: twee schermen die iets anders beweren.
Wat niet betrouwbaar te meten is, meet ik niet. Eén leverancier levert cijfers over verbruikte rekentijd die aantoonbaar niet kloppen. Die zijn eruit gegaan in plaats van meegenomen met een slag om de arm — een getal waarvan je weet dat het niet klopt, is schadelijker dan geen getal.
Technische verdieping
Gebruikte technologie
- Google Cloud Run
- BigQuery
- Terraform
- Next.js
- TypeScript
- Lighthouse
- Search Console API
- Sentry
Wat het opleverde
Het cijfer dat er het meest toe doet, staat niet in een tabel: het systeem heeft meermaals een klein foutje zichtbaar gemaakt dat, als het was blijven staan, geld had gekost — het soort verbruik dat ongemerkt oploopt tot het op je rekening staat. Daar was het voor gebouwd: niet om te waarschuwen als er iets kapot is, maar als er iets langzaam de verkeerde kant op gaat.
Het dagelijkse overzicht werd gewoon onderdeel van de ochtend. Het kwam binnen in de chat waar de rest van het werk ook langskwam — geen extra scherm om te openen, geen gewoonte om aan te leren. En het geheel stond er in ongeveer 26 uur, verdeeld over twee dagen: elf ophalers, de volledige database-inrichting, authenticatie en 83 tests. Dat tempo komt niet uit hard werken maar uit de werkwijze: gebouwd samen met AI-agents, met mijzelf als degene die beslist wat erin gaat.
- Plekken om te kijken
- Niets meer om zelf te zoeken
- Zes losse dashboards → Eén bericht per dag
- Bewaakte sites en signalen
- 11 ophalers op eigen schema
- Handmatig, onregelmatig → 4 sites, 9 soorten signalen
- Bouwtijd
- Inclusief 83 tests
- — → ~26 uur over twee dagen
Opgeleverd
- 4 sites op 9 soorten signalen
- 11 ophalers, dagelijks bericht om 08:00
- 83 geautomatiseerde tests
- Meermaals oplopend verbruik opgemerkt voordat het geld kostte
Uitkomsten
- Meermaals een oplopend verbruik opgemerkt voordat het op de rekening stond
- Het dagelijkse overzicht kwam binnen waar het werk al langskwam
- Grenswaarden staan op één plek, dus bericht en dashboard spreken elkaar niet tegen
- Het meetsysteem is losgekoppeld van wat het meet en valt er dus niet mee om
Wat ik ervan meeneem
Lessen
- Eén oordeel per dag is bruikbaar; tien dashboards zijn dat niet
- Grenswaarden horen op één plek — twee definities van ‘te traag’ geven gegarandeerd twee antwoorden
- Een meetsysteem dat afhankelijk is van wat het meet, meet niets op het moment dat het ertoe doet
- Onbetrouwbare cijfers weglaten is beter dan ze tonen met een voetnoot
- Bewaking is vooral nuttig voor wat langzaam de verkeerde kant op gaat
Wat hier werd uitgeprobeerd, neem ik mee naar klantwerk: één samenvattend bericht in plaats van een dashboard, grenswaarden op één plek, en de regel dat een meetsysteem nooit afhankelijk mag zijn van wat het meet.