Er is een verraderlijk soort geruststelling in een groen lampje. Alles staat op groen, dus alles werkt. Ik heb inmiddels genoeg schade opgelopen om dat lampje te wantrouwen. Want een groen lampje bewijst bijna nooit wat je denkt dat het bewijst. Het bewijst dat je server aanstaat. Of jouw klant nog een bevestigingsmail krijgt, of je beveiliging nog iets ziet, of je bezoekers nog een werkende pagina krijgen: daar zegt dat lampje helemaal niets over.

In dit stuk deel ik drie keren dat een controle bij mij vrolijk “gezond” meldde terwijl de kernfunctie er stilletjes bij lag. Drie totaal verschillende systemen, maar precies dezelfde denkfout eronder. En die denkfout zit waarschijnlijk ook in jouw bedrijf, of je nu zelf iets bouwt of een leverancier het voor je draait.

Geval één: “200 OK” terwijl de mail negen dagen dood was#

De klassieker onder de stille storingen. Een van mijn systemen verstuurde automatisch e-mails: bevestigingen, inloglinks, dat soort verkeer. Ik had er een gezondheidscontrole op gezet die keurig elke minuut een seintje gaf: de applicatie reageert, antwoordcode 200, alles in orde. Groen lampje.

Alleen: een deel van die mails kwam nooit aan. Negen dagen lang niet. De controle keek namelijk of de applicatie reageerde, en dat deed die netjes. Wat de controle niet deed, was daadwerkelijk een mail versturen en kijken of hij aankwam. De webpagina leefde, dus het lampje was groen. De functie waar het echt om ging, het versturen van mail, was dood.

De les hier is niet “monitor je mail beter”. De les is fundamenteler: mijn controle testte of de server ademhaalde, niet of hij zijn werk deed. Dat zijn twee compleet verschillende vragen. En bij een bedrijf betaalt de klant je voor het tweede.

Geval twee: een “gezonde” beveiligingslaag zonder detectieregels#

Het tweede geval is subtieler, en juist daarom leerzamer. Ik draaide een stukje beveiligingssoftware dat netwerkverkeer moet bewaken en alarm moet slaan bij verdachte patronen. Na een herstart meldde die laag zichzelf trots als gezond: motor gestart, proces draait, status groen. Precies wat je wilt zien.

Wat ik pas later ontdekte: de motor was wel gestart, maar er waren nul detectieregels geladen. Het ding stond als een bewakingscamera zonder film erin. Het lampje brandde, het proces draaide, maar er was letterlijk niets om verdacht gedrag mee te herkennen. Een aanval had er ongehinderd langs kunnen wandelen en het systeem zou trots “gezond” zijn blijven melden.

Dit is het gevaarlijkste soort valse gezondheid, want het geeft je een vals gevoel van veiligheid. Ik dacht dat ik bewaakt werd. In werkelijkheid keek er niemand. De gezondheidscontrole vroeg “draait het proces?” terwijl de enige zinnige vraag was: “kan dit ding überhaupt nog iets detecteren?”

Geval drie: de stille bewaker terwijl elke pagina 404 gaf#

Het derde geval is bijna komisch, als het niet zo pijnlijk was. Ik had een bewaker die websites in de gaten hield. Zolang die bewaker een antwoord kreeg van de site, bleef hij stil, en stilte betekende: alles goed.

Op een gegeven moment gaf elke pagina van een site een 404, oftewel “pagina niet gevonden”. De site was inhoudelijk kapot. Maar technisch gezien kreeg de bewaker wél een keurig antwoord terug, want een 404 is nog steeds een antwoord. De bewaker registreerde: er komt iets terug, dus de site leeft. En hij bleef stil. Bezoekers zagen niets dan foutpagina’s, en mijn monitoring vond dat prima.

Ook hier weer dezelfde bodem onder de fout: de controle keek of er een reactie was, niet of die reactie ergens op sloeg. Bereikbaar is niet hetzelfde als werkend.

De rode draad: test de functie, niet het teken van leven#

Als je die drie voorvallen naast elkaar legt, zie je hetzelfde patroon. In alle drie de gevallen mat mijn controle een makkelijk meetbaar signaal (reageert de server, draait het proces, komt er een antwoord) en behandelde dat als bewijs voor iets veel groters (werkt de dienst nog?). Het makkelijk meetbare is bijna nooit hetzelfde als het belangrijke.

Waarom trappen we hier zo massaal in? Omdat een gemakkelijke controle nu eenmaal gemakkelijk te bouwen is. “Reageert de server op poort X” schrijf je in vijf minuten. “Komt er echt een testmail aan in een echte inbox” kost meer werk, meer nadenken, en meer onderhoud. Dus kiezen we onbewust voor het lampje dat makkelijk groen te krijgen is, en noemen dat monitoring.

Sinds deze drie voorvallen hanteer ik een simpele regel voor elke gezondheidscontrole die ik maak of laat maken: de controle moet de échte functie uitvoeren, niet een teken van leven aftikken.

Concreet betekent dat:

  • Voor mail: laat de controle periodiek een echte mail versturen en in een echte inbox bevestigen dat hij aankwam, spammap incluis. Niet “reageert de app”, maar “arriveert de mail”.
  • Voor een beveiligingslaag: controleer niet of het proces draait, maar of het daadwerkelijk kan detecteren. Zijn er regels geladen? Vuurt een testsignaal een alarm af? Een bewaker die niets kan zien, is geen bewaker.
  • Voor een website: controleer niet of er íets terugkomt, maar of de juiste inhoud terugkomt. Zoek naar een woord dat op een werkende pagina hoort te staan. Een 404 of een lege pagina moet je monitoring rood laten kleuren, niet groen.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen software te bouwen om hier last van te hebben. Elk bedrijf leunt tegenwoordig op systemen die stilletjes hun werk moeten doen: een webshop die orders doorzet, een boekingssysteem dat bevestigingen stuurt, een koppeling die facturen naar je boekhouding schuift. Overal waar zo’n systeem “gezond” of “online” meldt, loont het om de vraag te stellen: gezond op basis van wát precies?

Drie dingen die je vandaag kunt doen, ook zonder technische pet:

  1. Vraag je leverancier wat “gezond” test. Als het antwoord neerkomt op “de server staat aan”, weet je genoeg. Vraag door tot je hoort dat de controle de daadwerkelijke functie uitvoert.
  2. Doe zelf periodiek de echte flow. Bestel een keer in je eigen webshop. Vraag een wachtwoord-reset aan op je eigen account. Boek een proefafspraak. Niks bewijst een werkende dienst zo goed als hem echt gebruiken.
  3. Wantrouw juist het interne verkeer. In mijn ervaring faalt precies datgene het hardst wat je het minst controleert. De klantgerichte flow test je nog wel eens. De interne, ogenschijnlijk saaie processen glippen jaren onopgemerkt door.

De duurste storingen zijn niet de storingen die luid crashen. Het zijn de storingen die glimlachen, groen kleuren en volhouden dat alles in orde is. Wie leert om de functie te testen in plaats van het lampje te geloven, vangt ze voordat een klant dat voor hem doet.

Wil je in kaart brengen waar in jouw bedrijf dit soort stille storingen op de loer liggen? Bekijk mijn gratis downloads of neem via de consulting-pagina contact op om je situatie door te lichten.