Ga naar de hoofdinhoud
BVDNET
Arnhem · websites & automatiseringBVDNET
← Alle projecten

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.