De sync die twee weken stil stond
Een dagelijkse data-sync bleek al twee weken niet meer te draaien. Er was geen foutmelding en geen alarm, dus niemand had het gemerkt.
Dat riep een ongemakkelijke vraag op. Het bedrijf had in de loop van maanden tientallen geautomatiseerde processen opgezet: dashboard-refreshes, data-syncs, backupscripts en monitoringchecks. Elk script was op een ander moment gebouwd, en niemand overzag het geheel. Waren er nog meer scripts ongemerkt gestopt?
Alles op tafel
We lieten Claude Code alle geautomatiseerde processen op beide machines inventariseren: LaunchAgents, cron jobs, achtergrondscripts en scheduled tasks. Per proces legden we vast wat het doet, wanneer het draait, wat de laatste succesvolle run was en of het nu nog werkt.
Van de 38 gevonden processen werkten er 9 niet meer.
Drie scripts waren gestopt door een permissie-wijziging na een OS-update, en twee verwezen naar een map die niet meer bestond. Nog eens twee schreven hun fouten naar een logbestand dat niemand las. Eén script draaide nog wel, maar leverde niets bruikbaars meer op sinds de bron-API was veranderd. Het laatste had een timingconflict met een ander script.
Repareren, en opschrijven waarom
Claude Code zocht per kapot script de oorzaak op en repareerde het. De permissies werden opnieuw ingesteld, de ontbrekende paden gecorrigeerd en de request-structuur aangepast aan de gewijzigde API. Het timingconflict was simpel op te lossen: de starttijden vijf minuten uit elkaar zetten.
Minstens zo belangrijk is het overzicht dat eruit kwam. Alle 38 processen staan nu gedocumenteerd: naam, doel, frequentie, locatie van het scriptbestand, verwachte output en hoe je controleert of het werkt. Ook iemand die er niet bij was, kan nu zien wat er ‘s nachts draait en waarom.
Wat er nu anders is
De negen gerepareerde scripts draaien weer. Er is ook een dagelijkse check bijgekomen die bevestigt dat alle scripts succesvol gedraaid hebben. Valt er nog eens een script stil, dan ziet het team dat bij die check.