Cron jobs uitgelegd — wp-cron vs echte server-cron

Wat is een cron job?

Cron is de standaard time-based scheduler van Unix/Linux-systemen. Hij draait sinds 1975, doet één ding en doet 't goed: "voer commando X uit op tijdstip Y, herhaaldelijk." Voorbeelden:

• Elke nacht om 03:00 een database-backup maken
• Elke 5 minuten een mail-queue verwerken
• Elke maandag om 09:00 een nieuwsbrief versturen
• Elke 15 minuten productprijzen synchroniseren met externe API

De configuratie bestaat uit een lijst regels (de "crontab") waarin elke regel zegt: "op deze tijden, dit commando."

Cron-syntax in 60 seconden

Een crontab-regel heeft 5 tijd-velden plus het commando:

* * * * * /pad/naar/script
│ │ │ │ │
│ │ │ │ └─ dag van de week (0-7, 0 en 7 zijn beide zondag)
│ │ │ └─── maand (1-12)
│ │ └───── dag van de maand (1-31)
│ └─────── uur (0-23)
└───────── minuut (0-59)

Voorbeelden:

• 0 3 * * * — elke dag om 03:00
• */5 * * * * — elke 5 minuten
• 0 9 * * 1 — elke maandag om 09:00
• 0 0 1 * * — eerste van elke maand om middernacht
• 15 14 * * 1-5 — werkdagen om 14:15

Tools als crontab.guru vertalen je expressie naar Nederlands voor je 'm activeert.

WordPress' wp-cron — hoe werkt het anders?

WordPress is gemaakt om op vrijwel elke shared hosting te werken — ook hosters waar je geen toegang hebt tot een echte cron. De bedenkers kozen voor een eigen alternatief: wp-cron.php. Het werkt zo:

1. WordPress houdt z'n eigen takenlijst bij in de database (in wp_options, optie cron)
2. Elke keer als iemand een pagina van je site bezoekt, controleert WP: "is er een geplande taak die nu uitgevoerd moet worden?"
3. Zo ja, wordt dat in de achtergrond afgehandeld via een aanroep naar wp-cron.php

Klinkt elegant. Werkt prima op kleine sites met regelmatig verkeer. Maar dezelfde aanpak heeft fundamentele problemen:

Drie problemen met wp-cron in de praktijk

1. Geen verkeer = geen cron

Site met weinig bezoekers heeft geen pageviews tijdens stille uren — geen pagineload betekent geen cron-trigger. Geplande posts blijven staan, mailings gaan niet uit, backups worden overgeslagen tot er weer iemand langskomt.

Symptoom: scheduled posts blijven hangen op "Missed Schedule", backups draaien onregelmatig.

2. Performance-impact bij elk pageload

Op high-traffic sites is het andersom: bij elk pageload wordt cron gecheckt — duizenden bezoekers per uur betekent duizenden cron-checks per uur. Niet inherent zwaar, maar met veel cron-jobs of zware tasks groeit het. Vooral als één cron-task 10 seconden duurt en die toevallig op een normale page-request triggert: bezoeker wacht onbedoeld 10 seconden.

Symptoom: trage frontend, vooral op piekmomenten. Soms 504-errors als de timeouts geraakt worden.

3. Niet betrouwbaar voor exact-timing

Cron-job ingesteld om elke 5 minuten te draaien? In WordPress betekent dat: "de eerstvolgende keer dat iemand de site bezoekt minstens 5 minuten na de vorige run." Geen verkeer 20 minuten? Cron heeft 20 minuten gewacht. Voor zaken als payment-callbacks of order-fulfillment is dat onbetrouwbaar.

Echte server-cron — hoe en wanneer instellen

Als je hosting je toegang geeft tot cron (vrijwel elke moderne NL-hoster doet dat), kun je beter overstappen op een echte cron-job die wp-cron.php aanroept volgens een vast schema. Niet meer afhankelijk van bezoekers, geen overhead op pageloads.

Stap 1: schakel WP-cron uit

In wp-config.php boven de regel "That's all":

define('DISABLE_WP_CRON', true);

Vanaf nu doet WordPress geen automatische cron-checks meer bij pageloads. Je móet daarna een echte cron instellen anders draait niets meer.

Stap 2: server-cron instellen via je control panel

cPanel

1. Cron Jobs (onder Advanced)
2. Common Settings: kies "Twice an hour" of "Every 15 minutes"
3. Command:

   /usr/local/bin/php /home/user/public_html/wp-cron.php >/dev/null 2>&1

4. Add New Cron Job

Plesk

1. Domains → klik domein → Scheduled Tasks
2. Add Task → "Run a command"
3. Command: /opt/plesk/php/8.2/bin/php /var/www/vhosts/jouwdomein.nl/httpdocs/wp-cron.php (PHP-versie aanpassen)
4. Run: bijv. "Every 15 minutes"

DirectAdmin

1. Account Manager → Cron Jobs
2. Vul minuut/uur etc. in (gebruik */15 * * * * via "Advanced")
3. Command: /usr/local/bin/php /home/user/domains/jouwdomein.nl/public_html/wp-cron.php

Via SSH (eigen server / VPS)

# Open crontab
crontab -e

# Voeg regel toe
*/15 * * * * /usr/bin/php /var/www/jouwsite.nl/wp-cron.php >/dev/null 2>&1

>/dev/null 2>&1 aan het eind voorkomt dat cron-output je mailbox volstuurt bij elke run.

Stap 3: test of 't werkt

Plugin als WP Crontrol installeren en kijken: zie je geplande events met "Next Run"-tijden in de toekomst? Worden ze afgevinkt zodra de cron-tijd voorbij is? Dan werkt 't.

Of via WP-CLI:

wp cron event list

Wanneer wp-cron behouden, wanneer overstappen?

WP-cron is prima als:

• Site krijgt minstens 1 bezoeker per kwartier
• Je hebt minder dan 10 actieve plugins die cron-tasks gebruiken
• Je hebt geen bedrijfskritische geplande tasks (alleen routine-onderhoud)
• Hosting biedt geen toegang tot cron (zeldzaam tegenwoordig)

Server-cron is beter als:

• Je hebt low-traffic site waar geplande posts of backups crucial zijn
• Je hebt high-traffic site waar elke milliseconde performance telt
• Je gebruikt WooCommerce — order-mails, abonnementen-renewals, voorraad-syncs vragen om voorspelbare cron
• Je hebt 503's tijdens piek-momenten — vaak ligt cron deels aan de oorzaak (zie 503 Service Unavailable oplossen)
• Je doet dagelijkse backups die niet gemist mogen worden
• Je gebruikt mailings of email-automation

Cron debugging — als geplande taken niet draaien

Check WP-cron-status

# WP-CLI
wp cron event list
wp cron event run --due-now
wp cron test

wp cron test probeert wp-cron.php aan te roepen en geeft terug of dat lukt. Faalt 't, dan is er een netwerk- of hosting-probleem.

Plugin: WP Crontrol

Geeft je een UI om alle geplande events te zien: welke task draait wanneer, wanneer is 'ie laatst gedraaid, welke is "missed". Onmisbaar voor troubleshooten.

Server-cron run history

• cPanel: Cron Jobs pagina toont laatste run-status
• Plesk: Scheduled Tasks → klik op task → "Run-history" tab
• SSH: tail /var/log/syslog | grep CRON of vergelijkbaar — exacte locatie hangt van OS af

Veelvoorkomende problemen

• "Missed Schedule" op posts — cron draait wel, maar te laat. Tijdsverschil tussen WP en server, of cron-interval te lang. Verlaag interval naar elke 5-10 minuten
• Cron werkt op staging maar niet op productie — hosting-permissies of DISABLE_WP_CRON-state verschilt
• Cron-job loopt te lang — kan andere taken blokkeren. Splits zware taken in batches via Action Scheduler (komt standaard met WooCommerce)
• Cron run, maar email-notificatie van resultaat ontbreekt — vaak wp_mail-issue, niet cron-issue. Zie WordPress emails komen niet aan

Andere CMS-en — Joomla, Drupal, OpenCart

Joomla, Drupal en OpenCart hebben vergelijkbare scheduled-task-systemen, vaak met dezelfde problematiek:

• Joomla: vanaf 4.x heeft Joomla z'n eigen Scheduled Tasks-component. Op grote sites: zelfde aanpak — Joomla's eigen scheduler uit, server-cron op de scheduler-URL
• Drupal: standaard wordt cron getriggerd via een module. Beter: server-cron op /cron.php?cron_key=... URL
• OpenCart: gebruikt een externe URL voor cron (index.php?route=feed/cron of vergelijkbaar). Server-cron erop instellen

Cron-jobs als deel van een hack-vector

Aanvallers misbruiken soms cron-jobs om persistentie te creëren — een geplande taak die elke 30 minuten een backdoor herstelt of opnieuw uploadt. Bij elk hack-onderzoek check ik daarom altijd:

# WordPress: lijst alle WP-cron events
wp cron event list

# Server-cron op shared hosting via paneel; via SSH:
crontab -l

Onbekende cron-tasks die met PHP draaien (php /pad/wpdefunct.php) of curls naar verdachte URL's? Verwijder eerst, daarna pas verder kijken. Zie ook Japanse SEO-spam in WordPress verwijderen, Chinese spam verwijderen, en Pharma hack verwijderen.

Wanneer schakel je hulp in?

• WP-cron werkt niet en je weet niet of 't aan WordPress-config, hosting-permissies of een plugin-bug ligt
• Je site krijgt 503's en je vermoedt dat cron deels de oorzaak is (te zware tasks, te vaak)
• Geplande posts blijven "Missed Schedule" ondanks server-cron-instelling
• WooCommerce-abonnementen renewals draaien niet of onregelmatig — gemiste omzet
• Backup-cron faalt zonder dat je 't merkt totdat je een backup nodig hebt — kostbaar moment
• Bij een hack-onderzoek vind je vreemde cron-events maar weet niet hoe te verwijderen zonder iets te breken
• Action Scheduler queue is opgelopen tot tienduizenden pending tasks — vraagt om opruiming

Cron is een fundamenteel onderdeel van een werkende site, maar onzichtbaar zolang 't werkt. Pas als 't faalt — gemiste mailings, niet-gepubliceerde posts, half-werkende abonnementen — wordt 't pijnlijk merkbaar. Eénmalig goed instellen (server-cron, niet wp-cron) en daarna een keer per kwartaal monitoren is voldoende voor de meeste sites.