PrestaShop cron jobs stop silently when you rename the admin folder

The symptom: everything looks fine, and nothing happens anymore

No error anywhere in the admin panel. No warning email. The store, a PrestaShop install, was up, selling, responding normally. The problem only surfaced by looking at a column almost nobody ever checks: updated_at in the ps_cronjobs table. Every single scheduled task in the back office, from rebuilding the sitemap to refreshing the search index, showed the exact same date, frozen for weeks. Every automated routine in the store had stopped at the same moment, and nobody had noticed, because stopping silently is exactly what this failure does: there's no error to look at, only the absence of something that's supposed to happen and doesn't.

What it looked like, and wasn't

Once you notice "something isn't running anymore", the temptation is to conclude too quickly that everything is broken at once. It wasn't, and it's worth telling what got checked and ruled out before reaching the real cause:

• Orders from an external sales channel looked stalled too. They weren't: they ran on a separate crontab line, independent from PrestaShop's own task scheduler, and it had never stopped working. The initial suspicion was wrong because it looked at the effect (fewer orders in that period) instead of the cause.
• The internal search index looked stale. It wasn't: PrestaShop updates a product's index entry the moment the product is saved, regardless of the cron. The scheduled "rebuild search index" task is only a full maintenance recalculation, useful but not the only way new products end up searchable. Spot-checked: products added after the cron stopped were already fully indexed.
• It could have been a permissions issue, or the operating system's cron service. Ruled out too: the crontab existed, the line was there, and it produced no visible error in the system logs. The problem wasn't that the cron never ran: it was that, when it did run, it didn't get what it expected.

The real cause: the /admin folder changed, and nobody updated whoever calls it

Renaming PrestaShop's admin folder (from /admin to something unpredictable) is a common security recommendation, one found in practically every guide on hardening a PrestaShop store. It's also, almost always, a one-time change that then gets forgotten.

The mechanism that runs PrestaShop's scheduled tasks, though, normally is not some internal process running on its own: it's a scheduled HTTP call (a system cron, or an external scheduling service) that every hour, or at whatever interval is configured, hits a specific URL, something like:

0 * * * * curl -k \
  "https://store.example/
   admin<oldname>/index.php
   ?controller=AdminCronJobs
   &token=..."

When the /admin<oldname> folder gets renamed for security, that call gets a 404. The AdminCronJobs controller never gets invoked, and so no scheduled task ever runs. There's no error message anywhere, because from PrestaShop's point of view nothing happened at all: nobody ever knocked on the right door. The date the folder was renamed and the date the tasks stopped updating, once checked, matched exactly.

The detail that makes this cause dangerous is precisely that renaming the admin folder is good security practice, not a mistake. Nobody instinctively connects it to "the cron jobs stopped", because the two seem to have nothing in common: one is about the panel's security, the other is about background automation. The link exists only because the cron trigger, technically, goes through the same address as the admin panel.

There was a second problem too, which only surfaced after manually running the most important task to confirm everything worked once the address was fixed: the validation token used by the sitemap regeneration URL no longer matched what the script expected. Even with the right address, that one task would have kept answering "invalid token" and doing nothing. Fixing the trigger alone isn't enough: every single task, when called by hand, needs to be verified to actually respond the way it should, not just that the crontab points to the right place.

The fix

1. Update the crontab with the correct admin folder name, after backing up the previous line.
2. Fix the token on the specific task that was invalid, so it starts running on its own again on the next scheduled pass.
3. Manually regenerate the stalled output, without waiting for the next automatic run: in the sitemap's case, the file had been frozen for weeks, and in the meantime search engines kept reading a file that said "nothing new here".
4. Check the content of the generated file too, not just that it exists: the sitemap index file carried a last-modified date years old, inherited from when it was first created, never updated automatically on each regeneration. That also had to be fixed by hand so it would stop lying to search engines.

How to verify it holds

• Call the correct URL by hand and check it returns 200 with the expected content, don't stop at "the crontab is updated".
• ps_cronjobs.updated_at actually moving, at the right hour. PrestaShop only runs each task within the time window it's scheduled for: a task scheduled for the middle of the night won't run if you call it in the afternoon. So the right verification isn't "I called the URL and it seems to work", it's "the next day, at its scheduled hour, that task actually updated its own date".
• Verify the output from the consumer's point of view: for a sitemap, that means checking it with a plain browser (200) and, in the server logs, confirming the real search engine crawler is actually fetching it successfully, not just that the file exists on disk.

The rule to take away, valid for any PrestaShop store: if the admin folder ever gets renamed again in the future, every place that calls it from the outside needs updating too, crontab included. Otherwise every scheduled routine stops again, silently, and the first signal arrives months later, when someone happens to notice an old date in a panel nobody usually looks at.

It's worth saying honestly, because it makes the problem more credible than any statistic could: it happened to us too, on our own store. Automated post-purchase review reminders never went out, for the exact same underlying reason: there was no cron for them, and the correct address to call was written down nowhere until we fixed it. This isn't a one-off that only happens to clients: it's an easy mistake for anyone running a PrestaShop store to make, including whoever wrote this article.