Home / Vault & Second Brain / Ik Bouwde Een Fix-Before-Alert Systeem — Mijn AI Lost Zijn Eigen Problemen Op

Ik Bouwde Een Fix-Before-Alert Systeem — Mijn AI Lost Zijn Eigen Problemen Op

Ik Bouwde Een Fix-Before-Alert Systeem — Mijn AI Lost Zijn Eigen Problemen Op

Ik heb een systeem gebouwd dat zijn eigen problemen oplost. Voordat ik er ook maar van weet. En eerlijk? Het is het meest bevrijdende dat ik dit jaar met mijn homelab heb gedaan.

Het begon met een frustratie die elke homelab-eigenaar kent: de constante stroom aan meldingen. Schijfruimte bijna vol. Een container die gecrasht is. Een backup die mislukt is. Mijn Telegram-kanaal vulde zich met ruis, en ik trainde mezelf om het te negeren. Dat is gevaarlijk — als er dan écht iets kritisch gebeurt, heb je al geleerd om weg te kijken.

Dus bouwde ik het Pulse Protocol. Het is een proces-naar-Agent push communicatiesysteem dat draait op mijn Hermes Agent stack. Elk proces in mijn homelab — cron jobs, backup scripts, systeemmonitors — stuurt een “puls” naar een centrale bridge. Die bridge vertaalt de puls naar een actiecode. En dan gebeurt er iets interessants: reflex-handlers proberen het probleem automatisch op te lossen.


De Fix-Before-Alert Filosofie

Het kernidee is simpel: stoor me alleen als de automatische fix faalt. Ik definieerde 10 actiecodes, maar de belangrijkste is ACTION_RECOVER — de bridge ziet een probleem, checkt of er een reflex bestaat, en voert die uit. Als de reflex slaagt, wordt het gelogd. Stil. Geen Telegram-bericht. Geen onderbreking. John blijft gefocust op wat er toe doet.

Mijn reflex-handlers doen onder andere:

  • Schijf opruimen — bij 90% vulgraad worden oude logs en temp-bestanden gewist
  • Container herstarten — als een Docker-container crasht, wordt deze automatisch herstart (max 3× per dag)
  • Model fallback — als Ollama 5 keer faalt in 10 minuten, schakel over naar een fallback provider
  • Script fixer — als een Python cron job faalt met ModuleNotFoundError, patch de wrapper automatisch
  • Zombie opruimer — hangende curl-processen die zich ophopen worden opgeruimd

Pas als een reflex faalt — of hetzelfde probleem blijft terugkomen — escaleert de bridge naar ACTION_ALERT, en krijg ik een helder, gestructureerd Telegram-bericht. Geen ruis. Alleen signaal.


Wat Ik Leerde Tijdens Het Bouwen

Het grootste inzicht was dit: de meeste alertsystemen zijn ontworpen voor het verkeerde. Ze zijn ontworpen om je te vertellen dat er iets mis is. Maar wat je eigenlijk nodig hebt is een systeem dat zegt er is iets mis en ik heb het al geprobeerd te fixen, hier is wat ik deed en of het werkte.

Het verschil is subtiel maar enorm. Mijn Telegram-kanaal ging van 25-40 berichten per dag naar ongeveer 2-3. En de berichten die ik wél krijg, zijn berichten waar ik echt iets mee moet. Het systeem respecteert mijn aandacht in plaats van ervoor te concurreren.

Ik draai dit nu ongeveer twee weken. De reflex-handlers vangen ongeveer 90% van de problemen af voordat ik ze zie. De overige 10% zijn problemen waar ik écht naar moet kijken — en omdat ik niet verdrink in de ruis, doe ik dat ook.


Hoe Dit Ook Voor Jou Kan Werken

Je hebt geen volledige Hermes Agent setup nodig om dit te proberen. Het kernconcept is simpel: elk proces in je systeem stuurt een gestructureerd signaal naar een centraal punt. Dat punt checkt of het probleem bekend en fixbaar is. Zo ja, fix het stil. Zo nee, escaleer. De sleutel is de reflex — een deterministische, geen-LLM-benodigde handler die direct draait.

Ik ben benieuwd: hoe ga jij om met alert fatigue in je eigen setup? Heb je ooit automatische herstelscripts gebouwd, of laat je je liever over alles notificeren? Laat het me weten in de reacties. Ik hoor graag hoe anderen de ruis temmen.

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *