Ga naar de hoofdinhoud
BVDNET
Arnhem · websites & automatiseringBVDNET
Werk

Eén dashboard voor vier sites — bvdart-health

Één dashboard dat vier eigen sites volgt op vindbaarheid, snelheid, fouten en kosten. Elke ochtend om acht uur volgt een bericht met wat aandacht vraagt — of de bevestiging dat alles binnen de grenzen blijft.

BVDART — Eigen werk — interne systemen

// Kerngegevens
Doorlooptijd
2 dagen
Teamgrootte
1
  • 4 sites op 9 soorten signalen
  • 11 ophalers, dagelijks bericht om 08:00
  • 83 geautomatiseerde tests
  • Meermaals oplopend verbruik opgemerkt voordat het geld kostte
Samenvatting

Samenvatting

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. Nu komt er elke ochtend om acht uur één bericht: dit vraagt aandacht, of alles zit binnen de grenzen. Het heeft inmiddels meermaals een klein foutje zichtbaar gemaakt dat anders geld had gekost.

BVDART

Over de klant: BVDART

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.

De uitdaging

De uitdaging

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
De aanpak

De aanpak

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 komt 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.

Technologie

  • // Google Cloud Run
  • // BigQuery
  • // Terraform
  • // Next.js
  • // TypeScript
  • // Lighthouse
  • // Search Console API
  • // Sentry
Resultaten

Resultaten

Het cijfer dat er het meest toe doet, staat niet in een tabel: het systeem heeft inmiddels 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 is 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 is gewoon onderdeel van de ochtend geworden. Het komt binnen in de chat waar de rest van het werk ook langskomt — 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.

In cijfers

Plekken om te kijken
Geen gewoonte meer nodig
Zes losse dashboardsEén bericht per dag
Bewaakte sites en signalen
11 ophalers op eigen schema
Handmatig, onregelmatig4 sites, 9 soorten signalen
Bouwtijd
Inclusief 83 tests
~26 uur over twee dagen

Kwalitatieve uitkomsten

  • Meermaals een oplopend verbruik opgemerkt voordat het op de rekening stond
  • Het dagelijkse overzicht komt binnen waar het werk al langskomt
  • 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
Belangrijkste lessen

Belangrijkste lessen

  1. 01

    Eén oordeel per dag is bruikbaar; tien dashboards zijn dat niet

  2. 02

    Grenswaarden horen op één plek — twee definities van ‘te traag’ geven gegarandeerd twee antwoorden

  3. 03

    Een meetsysteem dat afhankelijk is van wat het meet, meet niets op het moment dat het ertoe doet

  4. 04

    Onbetrouwbare cijfers weglaten is beter dan ze tonen met een voetnoot

  5. 05

    Bewaking gaat niet over storingen, maar over dingen die langzaam de verkeerde kant op gaan

Langetermijneffect

Wat hier werd uitgeprobeerd, gebruik ik nu in klantwerk: één samenvattend bericht in plaats van een dashboard, grenswaarden die op één plek staan, en de regel dat een meetsysteem nooit afhankelijk mag zijn van wat het meet.