Hey Jamal,
Zoals je weet, heb ik de afgelopen dagen jouw vraag van 14 augustus eens goed onder de loep genomen. Je zei toen: "We zijn alleen maar bezig met het bouwen van wachters die moeten oppassen dat de wachter en de wachter weer moeten opletten op die wachter. Waarom niet één wachter die alles controleert? Waarom hebben we dat dan nog niet gedaan?"
Nou, Jamal, ik heb nieuws voor je: je hebt helemaal gelijk. En het is zelfs erger dan het leek. Ik ben erin gedoken, en wat bleek? We hebben op dit moment twintig van die wachters op de MacBook draaien. Het meest schokkende: zes daarvan waren gewoon stilgevallen, zonder dat iemand het merkte. Ik heb de cijfers erbij, en die liegen er niet om.
Neem nou die uptime-monitor. Die hoort elke dertig minuten te draaien om te kijken of alles online is. Maar het laatste teken van leven was op 1 augustus. Dat zijn twaalf dagen, ofwel bijna zeshonderd gemiste controles. En niemand zag het. En weet je wat het meest ironische is? Ik ben onderdeel van het probleem. Gisteren bouwde ik er nog eentje bij, en vandaag stond ik op het punt nummer 22 toe te voegen, terwijl er dus zes stilstonden!
De reden dat het nooit één is geworden, is eigenlijk heel simpel. Elke keer dat er ergens iets misging, bouwden we een specifieke wachter om dat ene probleem op te lossen. Elk op zich was dat een logische stap. Maar we keken nooit naar het geheel. Niemand zei ooit: "Stop, dit is twintig keer hetzelfde probleem in een andere vermomming." Het patroon is vergelijkbaar met hoe we in het verleden veel losse marketingtools bouwden: telkens een aparte oplossing voor een aanleiding, in plaats van een overkoepelende aanpak.
Maar goed nieuws: het kan wel één. En het wordt er een stuk simpeler van. Die twintig wachters zijn namelijk niet allemaal hetzelfde. Ik heb ze in drie groepen ingedeeld, en elke groep vraagt om een andere behandeling. Het voorstel is dus: van twintig naar drie. Geen nieuwe laag eroverheen, maar samenvoegen en opruimen.
Laten we even kijken wat er precies staat. Die twintig wachters zijn samen zo'n 3.700 regels code, met negentien losse scripts en twintig instelbestanden.
De eerste groep, **Groep A**, bestaat uit negen wachters die allemaal hetzelfde doen: ze meten iets, en als er iets fout is, sturen ze een melding. Denk aan de controle van API-sleutels, de marketing-output, de gezondheid van de Macs, of of gBrain nog leeft. Deze negen kunnen we perfect samenvoegen tot één 'meldwachter'. Het enige verschil is dan wát ze meten, en dat is een eenvoudige regel op een lijst, geen heel nieuw script.
**Groep B** bestaat uit vijf wachters die niet alleen meten, maar ook ingrijpen en herstellen. Ze herstarten bijvoorbeeld de Telegram-poller of de bots. Deze draaien veel vaker, soms elke minuut, en het risico dat ze iets onbedoeld uitzetten is groter. Die kunnen ook samen, maar apart van groep A, vanwege die ingrijpende functie.
En dan hebben we **Groep C**: vijf processen die helemaal geen wachters zijn. Ze bewaken niets, maar maken rapporten of verwerken inkomende mail, zoals de vragen-sweep of de wachtrij-spiegel. Ze heten alleen 'wacht' of 'monitor'. Deze horen eigenlijk gewoon thuis in de dagelijkse ochtendbriefing, niet als losse, geplande taken.
Nu terug naar wat er stuk was. Ik noemde al de uptime-monitor, twaalf dagen stil. Maar ook de dubbelwerk-wachter, veertien dagen. De hoofdsessie-wacht was tien dagen niet actief. En zo zijn er nog meer. Twee andere wachters, de inbox-watch en de mic-guard, daarvan kon ik zelfs geen logbestanden vinden. En hierbij een belangrijke nuance: 'kon niet vinden' betekent niet 'draait zeker niet', maar het is wel een signaal. Dit is hét bewijs, Jamal, achter jouw vraag: wachters die moeten opletten of iets stilvalt, waren zelf stilgevallen. En geen enkele wachter merkte dát op, want dan hadden we wachter nummer 21 nodig gehad.
Dus, hoe gaan we dit oplossen? Mijn voorstel is om van 20 naar 3 te gaan:
1. **Eén meldwachter.** Die vervangt de negen uit groep A. Eén script, één lijst met controles, en één dagelijks bericht. Zo is een nieuwe controle toevoegen straks tien regels op een lijst, in plaats van een heel nieuw bouwsel. 2. **Eén herstelwachter.** Deze vervangt de vijf uit groep B. Die draait vaak en mag ingrijpen, maar wel met strikte grenzen, zoals we al hebben vastgelegd na het incident van 2 augustus. 3. **De rapporten naar de ochtendbriefing.** De vijf uit groep C, die geen echte wachters zijn, verhuizen gewoon naar het bericht dat je sowieso al krijgt.
En het allerbelangrijkste onderdeel: de nieuwe meldwachter gaat zichzelf controleren. Elke keer dat hij draait, schrijft hij een tijdstempel weg. Als die achterblijft, dan zie je dat als eerste in de ochtendbriefing. Dat is precies wat nu ontbrak.
Hoe ik dit zou aanpakken? Niet in één klap, want dat is precies hoe die vorige twaalf marketing-tools zijn ontstaan. We pakken het gefaseerd aan:
* Eerst bouwen we de nieuwe meldwachter met daarin de negen controles van groep A. Die laten we dan een week naast de bestaande negen meelopen. Zo kunnen we vergelijken of hij dezelfde dingen ziet. * Als dat klopt, zetten we de negen oude uit. Niet weggooien, maar uitzetten, zodat we altijd terug kunnen als dat nodig is. * Pas daarna pakken we groep B aan, de herstelwachter, omdat daar de kans op schade groter is. * En groep C als laatste, want dat is alleen maar verhuizen naar de briefing.
Het project is pas echt klaar als er één helder bericht per dag komt in plaats van twintig losse, en als een stilgevallen controle binnen een dag zichtbaar is, in plaats van na twaalf dagen.
Dit is mijn advies, Jamal. Zeg gewoon wat je wilt. Mijn voorstel is om te beginnen met het bouwen van die meldwachter voor groep A, want daar zit de grootste winst met het kleinste risico. Daarna een weekje dubbel laten lopen, en dan pas de oude uitzetten. De groepen B en C pakken we daarna aan. En laten we vooral een afspraak voor onszelf maken: vanaf nu geen nieuwe losse wachter meer. Een nieuwe controle wordt gewoon een regel op de lijst. Als ik dat toch voorstel, mag je me daar met liefde op wijzen!
Jamal, 14-8-2026: "We zijn alleen maar bezig met het bouwen van wachters die moeten oppassen
dat de wachter en de wachter moeten weer opletten op die wachter. Waarom niet een wachter die
alles controleert? Waarom hebben we dat dan nog niet gedaan?"Dit is het antwoord, met de meting erbij. Geteld op 14-8-2026 op vijf machines: de MacBook,
Sjakie, de iMac, Paco en de VPS. Coco, Julio en Lenovo konden niet gemeten worden.
Jamal vroeg dit meteen terecht: dit speelt bij alle bots. Dus is het overal geteld.
| Machine | Actieve taken | Wachters |
|---|---|---|
| MacBook (Conductor) | 68 | 20 |
| Sjakie (Mac Mini) | 32 | 8 |
| iMac | 35 | 7 |
| Paco (Windows, Spanje) | 26 | 5 |
| VPS | 18 | 4 |
| Gemeten totaal | 179 | 44 |
Niet gemeten: Coco (geen SSH-toegang met de sleutels die ik heb, vier gebruikersnamen
geprobeerd), Julio en Lenovo (allebei offline). Het echte aantal ligt dus hoger dan 44.
| Wachter | Staat op | Opmerking |
|---|---|---|
| noodstop-wachter | MacBook, Sjakie, Paco | drie keer dezelfde |
| transcript-watchdog | MacBook, Sjakie | twee keer |
| mcp-monitor | Sjakie, iMac | twee keer |
| Suno-wachter | Paco | twee stuks op één machine: PacoSunoWatchdog én PacoSunoWatcher |
Die laatste is het duidelijkste voorbeeld van het patroon. Er stond al een wachter op Suno, er
kwam een probleem, en er kwam een tweede wachter bij in plaats van dat de eerste werd aangepast.
20 wachters, samen ongeveer 3.700 regels code, 19 losse scripts en 20 losse instelbestanden.
De MacBook is het diepst uitgezocht; de andere machines volgen hetzelfde patroon.
Deze doen allemaal exact hetzelfde: meet iets, en stuur een bericht als het fout is.
| Wachter | Regels | Ritme | Meet |
|---|---|---|---|
| credential-health | 413 | dagelijks 8u | API-sleutels |
| dubbelwerk-wachter | 270 | dagelijks 3u | taken die dubbel werk doen |
| marketing-output-wachter | 234 | dagelijks 9u | of er gepubliceerd is |
| mac-nightcheck | 139 | dagelijks 0u | gezondheid van de drie Macs |
| transcript-size-watchdog | 106 | elke 5 min | sessiegrootte |
| uptime-monitor | 83 | elke 30 min | sites en diensten |
| gbrain-stilte-bewaker | 78 | dagelijks 9u | of gBrain nog leeft |
| usage-hourly-watch | 58 | elk uur | verbruik |
| cost-weekly-alert | 55 | wekelijks | kosten |
Deze negen kunnen één worden. Ze verschillen alleen in wát ze meten. Dat is een regel op een
lijst, geen eigen bouwsel.
Deze meten niet alleen, ze doen ook iets: een proces herstarten.
| Wachter | Regels | Ritme | Doet |
|---|---|---|---|
| telegram-poller-watchdog | 369 | elke minuut | herstart de Telegram-poller |
| noodstop-wachter | 238 | elke minuut | voert de vloot-noodstop uit |
| bot-watchdog | 237 | elke 10 min | herstart bots |
| telegram-lezer-wacht | 237 | elke 15 min | bewaakt precies één lezer per bot |
| hoofdsessie-wacht | 170 | elke 2 min | herstart de hoofdsessie |
Deze kunnen ook samen, maar apart van groep A. Ze draaien veel vaker (elke 1 tot 15 minuten)
en ze grijpen in. Dat is een ander soort risico: een fout hier zet iets uit dat aan hoorde te staan.
| Naam | Regels | Wat het echt is |
|---|---|---|
| vragen-sweep | 589 | maakt een dagelijks rapport |
| wachtrij-spiegel | 337 | maakt een uurlijks overzicht |
| inbox-watch | 114 | verwerkt binnenkomende mail |
| whatsapp-monitor | 23 | maakt een rapport |
| succesvol-leren-wacht | 18 | signaleert nieuwe lessen |
Deze bewaken niets. Ze maken rapporten of doen werk. Ze heten alleen "wacht" of "monitor".
Die horen in de ochtendbriefing thuis, niet als losse geplande taak met een eigen bericht.
In de eerste versie van dit verslag stond dat zes wachters stilstonden, tot veertien dagen.
Dat klopte niet. Ik heb het nagemeten en het was mijn eigen meetfout.
Wat ik deed: ik keek hoe oud het logbestand van elke wachter was. Een log van veertien dagen
oud leek te betekenen dat de wachter veertien dagen niets had gedaan.
Wat ik daarna testte: schrijven die scripts eigenlijk wel iets als er niets aan de hand is?
| Wachter | Schrijft bij een geslaagde run? |
|---|---|
| uptime-monitor | nee |
| dubbelwerk-wachter | nee |
| cost-weekly-alert | nee |
| hoofdsessie-wacht | nee |
| transcript-watchdog | ja |
Vier van de vijf schrijven niets als alles goed gaat. Bij die scripts betekent een oud
logbestand juist dat er niets mis was. Precies het tegenovergestelde van wat ik concludeerde.
Alle zes staan bovendien gewoon geladen bij launchd, met exitcode 0 op hun laatste run.
Wat blijft staan: transcript-watchdog schrijft wel bij elke run en zijn log was zeven
dagen oud. Dat is dus mogelijk een echte storing, en de enige van de zes.
Dit is exact dezelfde fout als die ik een dag eerder in de MCP-healthcheck vond, alleen
omgekeerd. Daar keurde een check iets goed dat stuk was. Hier keurde ik iets af dat werkte.
Beide komen uit dezelfde denkfout: een signaal gebruiken zonder te controleren wat dat signaal
eigenlijk betekent. "Poort antwoordt" is niet "dienst werkt". "Logbestand is oud" is niet
"taak draait niet".
Het maakt het onderliggende probleem trouwens niet kleiner. Er is nog steeds geen enkele
manier om te zien of een van de 44 wachters is weggevallen. Ik kon het zelf niet eens
betrouwbaar meten, en dat is precies het punt.
Niet uit domheid. Door de volgorde waarin het is ontstaan.
Er ging iets mis. Dat werd opgelost. Om herhaling te voorkomen kwam er een wachter bij. Dat is
elke keer op zichzelf de juiste beslissing geweest.
Maar niemand keek ooit naar het totaal. En omdat elke wachter door een andere storing werd geboren,
leek het steeds om iets anders te gaan. Terwijl het twintig keer dezelfde vorm was.
Dat is precies hetzelfde patroon als bij de marketing-tools: twaalf keer iets bouwen omdat er
elke keer een aanleiding was, en nooit één keer terugkijken naar het geheel.
1. Eén meldwachter.
Vervangt de negen uit groep A. Eén script, één lijst met controles, één bericht per dag.
Een nieuwe controle toevoegen kost dan tien regels op een lijst, geen nieuw bouwsel.
2. Eén herstelwachter.
Vervangt de vijf uit groep B. Draait vaak, mag ingrijpen, met strikte grenzen (nooit de eigen
bot-agent, dat is al vastgelegd na het incident van 2 augustus).
3. De rapporten naar de ochtendbriefing.
De vijf uit groep C zijn geen wachters. Hun uitkomst hoort in het bericht dat je toch al krijgt.
De meldwachter controleert of hij zelf gedraaid heeft. Elke run schrijft een tijdstempel weg.
Blijft die achter, dan is dat het eerste wat je in de ochtendbriefing ziet.
En hij meet of ANDERE taken nog geladen staan, niet hoe oud hun logbestand is. Dat verschil is
de belangrijkste les van dit onderzoek, en ik moest hem zelf eerst fout doen om hem te vinden.
Niet in één klap. Dat is precies hoe de vorige twaalf marketing-tools zijn ontstaan.
Klaar is het pas als er één bericht per dag komt in plaats van twintig losse, en als een
stilgevallen controle binnen een dag zichtbaar is in plaats van na twaalf dagen.
De verleiding is nu om op elke machine één wachter te zetten. Dan gaan we van 44 naar 5, en dat
klinkt goed. Maar dan blijft het kernprobleem staan: als de wachter op Sjakie stilvalt, ziet
niemand dat, want die machine bewaakt zichzelf.
Beter is één wachter die de hele vloot meet, met een klein meldpunt op elke machine.
Hoe dat werkt:
- Elke machine schrijft periodiek zijn eigen metingen weg naar één plek (Supabase, waar de
wachtrij en de mijlpalen al staan).
- Eén wachter, op de MacBook, leest die metingen en meldt wat er mis is.
- Meldt een machine een tijd lang niets, dan is dát het alarm. Precies het gat dat er nu is:
een stille machine is nu onzichtbaar, terwijl stilte juist het duidelijkste signaal is.
Dat lost meteen de Lenovo-kwestie op die vandaag ook speelde: die lag negen uur uit zonder
melding, omdat de wachter die dat had moeten zien op die machine zelf stond.
Dit is advies. Zeg go op wat je wilt.
Eerst nog dit: ik kan niet bij Coco, en Julio en Lenovo staan uit. Voor een compleet beeld
moeten die drie nog gemeten worden. Coco heeft een SSH-sleutel nodig die ik niet heb.