Blijft in Magento een mail, voorraadupdate of prijswijziging uit? Dan ligt dat meestal aan cron of aan de message queues. Magento draait zelf geen achtergrondtaken: een crontab-regel roept elke minuut bin/magento cron:run aan, aangemaakt via bin/magento cron:install (Adobe Experience League). Verdwijnt die regel, bijvoorbeeld na een servermigratie, een PHP-upgrade met een ander pad, of een vastgelopen proces, dan stoppen tientallen achtergrondtaken in één keer, zonder dat er op het eerste gezicht iets stuk lijkt.
Wat je als eerste merkt
De symptomen lijken los van elkaar te staan, maar komen vaak uit dezelfde twee systemen:
- Orderbevestigingen komen niet of laat aan (alleen relevant als asynchroon verzenden aanstaat, zie verderop)
- Prijzen, voorraad en catalogusprijsregels zijn pas na uren zichtbaar op de site
- “Reindex required” in System > Index Management blijft staan, ook na een tijdje wachten
- Sitemap en productfeeds worden niet ververst
- Geplande prijsregels starten niet op het ingestelde moment
- Exports naar je ERP blijven hangen
- Orders met status Pending Payment worden niet automatisch geannuleerd
In de meeste gevallen komt het neer op een van twee dingen: cron staat stil, of de consumers die berichten uit de queue halen draaien niet.
Cron en queues in gewone taal
Cron is Magento’s eigen takenlijst. Elke geplande taak staat in de tabel cron_schedule, gegroepeerd per cron group (zoals default en index). Een taak loopt pas als de aanroep van bin/magento cron:run, elke minuut, hem oppikt.
Message queues zijn iets anders: berichten die in een wachtrij staan tot een consumer ze oppakt, opgeslagen in de database (MySQL) of in RabbitMQ. Die consumers start Magento standaard via een eigen cronjob, consumers_runner. Een consumer verwerkt standaard 10.000 berichten, stopt dan en wordt bij de volgende cronrun opnieuw gestart (Adobe Experience League). Staat cron stil, dan start er dus ook geen enkele consumer meer opnieuw op. Een veelgebruikt alternatief is Supervisor, waarmee consumers los van cron blijven draaien.
| Wat het is | Wie start het | Als het stilstaat | |
|---|---|---|---|
| Cron | Magento’s takenlijst in cron_schedule |
Elke minuut bin/magento cron:run |
Alle geplande taken stoppen tegelijk |
| Message queues | Berichten die wachten op een consumer | consumers_runner via cron, of Supervisor |
Exports en updates blijven in de wachtrij |
| Indexer-modus | Direct (Update on Save) of op de achtergrond (Update by Schedule) | Bij schedule: cron | “Reindex required” blijft staan |
Daarnaast speelt de indexer-modus een rol: Update on Save verwerkt een wijziging direct, Update by Schedule doet dat op de achtergrond via cron. Sinds Magento 2.4.8 is Update by Schedule de standaard voor nieuwe installaties en nieuwe indexers, maar bestaande indexers op een bestaande shop wijzigen daarbij niet automatisch mee (release notes 2.4.8). Hoe die twee standen precies werken en waarom schedule bij veel verkeer de aangeraden keuze is, staat al uitgewerkt in de voorbereiding op Black Friday.
Wat je zelf checkt, zonder SSH
Een deel hiervan zie je direct in de admin.
Open System > Index Management en kijk of er indexers op “Reindex required” staan die niet worden weggewerkt. Blijft dat zo, dan is dat een signaal dat cron (of specifiek de index cron group) niet draait.
Check vervolgens Stores > Configuration > Sales > Sales Emails > General Settings > Asynchronous sending. Deze instelling staat standaard op Disable, waardoor een orderbevestiging direct bij het plaatsen van de order wordt verstuurd. Staat hij op Enable, dan wordt die mail via cron verstuurd en hangt de aflevering af van dezelfde cron die ook alles hierboven raakt (Adobe Experience League).
Kijk ook naar Stores > Configuration > Sales > Sales > Orders Cron Settings. Daar staat de Pending Payment Order Lifetime, standaard 480 minuten (Adobe Experience League). Blijven onbetaalde orders na die tijd nog gewoon open staan, dan is ook dat een aanwijzing dat de bijbehorende cronjob niet draait.
Tip: een simpele test. Wijzig een prijs of voorraadniveau, noteer het tijdstip, en kijk of de wijziging op de site zichtbaar is. Zie je hem na een kwartier nog niet, dan is er iets mis, welke indexer-modus je ook gebruikt.
Let op: niet elke gemiste mail ligt aan cron. Een haperende betaalmodule of een mailserver die weigert, geeft hetzelfde symptoom.
Wat je developer of hoster checkt
Dit gedeelte gaat verder dan de admin. Stuur deze lijst door naar je developer of hoster:
- Staat de crontab-regel er nog, en wijst die naar het juiste PHP-pad? Na een PHP-upgrade of servermigratie gaat dat vaak stil mis.
- Hoeveel taken in
cron_schedulestaan opmissedoferror, en welke staan al lang oprunning? Reset die status niet blind: de knowledge base van Adobe legt uit hoe je een vastgelopen job herkent en afhandelt, geschreven voor Adobe Commerce on cloud maar de aanpak is vergelijkbaar (Adobe Experience League). - Draaien de consumers, en zijn ze na de laatste deploy herstart? Een consumer die doorloopt, houdt anders de oude code vast.
- Wat staat er onder
cron_consumers_runnerinapp/etc/env.php(standaardcron_runaan,max_messages10000), en past dat bij hoe de shop draait (via cron of via Supervisor)? - Welke modus heeft elke indexer (
bin/magento indexer:show-mode), en is dat nog de juiste keuze? - Bij meerdere servers: draait cron op precies één server?
Wil je dat je developer hier technisch dieper induikt, dan is deze uitleg over Magento 2 cronjobs configureren een goed vertrekpunt.
Stil is niet hetzelfde als goed
Cron en queues vallen niemand op zolang ze draaien, en ook niet als ze stoppen. Je merkt het pas aan de klant die geen bevestiging kreeg, of aan voorraad die al een dag niet klopt.
Wil je dit structureel laten bewaken, dan hoort dat bij doorlopend Magento onderhoud. Twijfel je of cron, queues en indexers nu goed staan, laat dat dan eenmalig nakijken in een Magento code review. Weet je niet waar je moet beginnen, neem contact op.
Neem je een shop over zonder te weten hoe de achtergrondtaken zijn ingericht, dan is dit een van de eerste dingen om te checken bij een Magento overname.
Veelgestelde vragen
Hoe vaak draait cron in Magento?
Elke minuut. De crontab-regel die bin/magento cron:install aanmaakt, roept elke minuut bin/magento cron:run aan. Alle geplande taken en de consumer-runner lopen via die aanroep.
Waarom blijft “Reindex required” staan in Index Management?
Meestal omdat cron de indexer niet bijwerkt. De melding betekent dat de index niet meer klopt met de data; normaal pakt een cronjob in de index cron group dat binnen een paar minuten op. Blijft hij staan, check dan of cron, en specifiek de index cron group, nog draait.
Waarom komt een orderbevestiging niet aan?
Meestal doordat asynchroon verzenden aanstaat in Sales Emails en cron niet draait, waardoor de mail nooit wordt verstuurd. Standaard staat die instelling op Disable en gaat de mail direct bij het plaatsen van de order, zonder cron ertussen. Niet elke gemiste mail komt overigens door cron: een betaalmodule of mailserver kan hetzelfde symptoom geven.
Worden onbetaalde orders automatisch geannuleerd?
Ja, standaard na 480 minuten, via de Pending Payment Order Lifetime-instelling onder Sales > Orders Cron Settings. Ook dat loopt via cron, dus staat cron stil, dan blijven die orders gewoon open staan.
Is een consumer hetzelfde als een cronjob?
Niet precies. Een consumer is een proces dat berichten uit een message queue verwerkt. Standaard wordt dat proces zelf gestart en herstart door een cronjob (consumers_runner), maar het is ook mogelijk om consumers los van cron te laten draaien, bijvoorbeeld via Supervisor.