Als een cronjob in Plesk niet draait, zie je vaak geen directe foutmelding op je scherm – het script faalt gewoon op de achtergrond. Het antwoord ligt meestal in de logbestanden: daar vind je exact wat er misging, of het nu gaat om een fout PHP-pad, een ontbrekende omgevingsvariabele of een permissieprobleem. In dit artikel loop je systematisch door het debugproces, van logs lezen tot de meest voorkomende oorzaken oplossen.
Hoe cronjobs in Plesk werken
Een cronjob is een geplande taak die op vaste tijden automatisch wordt uitgevoerd, bijvoorbeeld om een database te synchroniseren, e-mails te versturen of een backup-script aan te roepen. In Plesk configureer je deze taken via Websites & Domains → Scheduled tasks (cronjobs), waarbij je een commando of script koppelt aan een tijdschema.
Op servers met LiteSpeed en NVMe-opslag draait de cron-service los van je webserver, wat betekent dat een trage website niet automatisch de oorzaak is van een mislukte cronjob – en omgekeerd. Het verschil tussen een werkende en falende taak is vaak klein: een ontbrekend absoluut pad, een verkeerde PHP-versie of een variabele die in een interactieve shell wél bestaat maar in de cron-omgeving niet.
Logbestanden controleren en interpreteren
De eerste stap bij het debuggen van een cronjob is altijd het logbestand bekijken. In Plesk vind je dit via Websites & Domains → Scheduled tasks, waar je per taak de uitvoergeschiedenis kunt inzien, of via Logs op domeinniveau.
Open Plesk en ga naar je domein
Log in op Plesk en navigeer naar het betreffende domein onder Websites & Domains.
Bekijk de scheduled tasks
Open de cronjob en klik op de uitvoerhistorie om de laatste runs en hun status te zien.
Zoek de foutmelding
Let op timestamps die overeenkomen met het geplande tijdstip van de taak en lees de volledige foutregel.
Herleid de oorzaak
Een foutmelding als ‚command not found‘ wijst vaak op een verkeerd pad, terwijl ‚permission denied‘ duidt op rechtenproblemen.
Veelvoorkomende problemen oplossen
De meeste cronjob-fouten komen terug op een klein aantal oorzaken:
Verkeerd PHP-pad: veel taken falen omdat het absolute pad naar PHP ontbreekt of niet overeenkomt met de gewenste PHP-versie. Controleer via SSH met which php welk pad correct is, en verwijs in de cronjob altijd naar het volledige pad in plaats van alleen php.
Ontbrekende omgevingsvariabelen: cron draait in een minimale shell zonder de variabelen die je gewend bent in een interactieve sessie. Zet benodigde variabelen zoals $PATH of $HOME expliciet in het script zelf.
Permissieproblemen: het script moet uitvoerbaar zijn (chmod +x script.sh) en de gebruiker waaronder de cronjob draait moet toegang hebben tot alle bestanden en mappen die het script aanspreekt.
Timeouts bij langlopende taken: grote imports of backups kunnen vastlopen als de uitvoeringstijd te kort is. Splits zware taken op in kleinere stappen of plan ze buiten piekmomenten.
Relatieve paden in scripts: een script dat lokaal werkt maar in cron faalt, gebruikt vaak relatieve paden die afhankelijk zijn van de werkmap. Gebruik altijd absolute paden naar bestanden en mappen.
Cronjobs testen en voorkomen van fouten
Test een nieuwe cronjob eerst handmatig via SSH door exact het commando uit te voeren zoals het in Plesk staat geconfigureerd. Zo zie je direct foutmeldingen in plaats van te wachten op de volgende geplande run.
Houd daarnaast rekening met afhankelijkheden: als een cronjob e-mails verstuurt, controleer dan of je e-mailconfiguratie correct is ingesteld, bijvoorbeeld via zakelijke e-mail met de juiste SPF- en DKIM-records. Draait de taak op een nieuw domein, controleer dan ook of de domeinnaam en DNS correct zijn doorgevoerd voordat je verwacht dat scripts extern bereikbaar zijn.
Loop je vast ondanks deze stappen, raadpleeg dan de kennisbank voor meer Plesk-uitleg of neem contact op met support.
Veelgestelde vragen
Waarom toont mijn cronjob geen enkele output?
Vaak omdat de output niet wordt opgevangen. Voeg >> /pad/log.txt 2>&1 toe aan het commando zodat zowel normale output als foutmeldingen worden weggeschreven.
Mijn script werkt via SSH maar niet via cron, hoe kan dat?
Dit komt bijna altijd door ontbrekende omgevingsvariabelen of relatieve paden. Gebruik absolute paden en zet benodigde variabelen expliciet in het script.
Hoe weet ik welke PHP-versie mijn cronjob gebruikt?
Controleer dit via SSH met which php of php -v, en zorg dat het pad in de cronjob exact overeenkomt met de gewenste versie.
Kan ik meerdere cronjobs tegelijk laten draaien?
Technisch wel, maar bij zware taken kun je serverbelasting krijgen. Plan taken verspreid over de dag, vooral bij gedeelde webhosting.
Wat doe ik als niets van dit helpt?
Verzamel de volledige foutmelding en het exacte commando en neem contact op met support, die kan meekijken in de serverlogs.
Conclusie
Cronjob fouten in Plesk zijn bijna altijd terug te leiden tot een logregel: begin daarom altijd met de logbestanden, controleer paden, rechten en omgevingsvariabelen, en test commando’s eerst handmatig via SSH. Met een gestructureerde aanpak los je de meeste fouten binnen enkele minuten op.