This has also been ongoing for years. We find systems that were backing up just fine until a maintenance pass, then the backups stop. No warnings, no errors, and a manual run of the job works. The only fix we’ve found is to delete the backup job and recreate.
Can you PLEASE find and fix whatever is causing this?
Two possibilities come to mind,
the logic in the install() function for the backup module (which runs any time the module is updated) is somehow buggy. It looks for old jobs named backup.php (new backup jobs do not have this name) and removes them:
$crons = $this->freepbx->Cron->getAll();
foreach($crons as $c) {
if(preg_match('/backup\.php/',(string) $c,$matches)) {
$this->freepbx->Cron->remove($c);
}
}
I don’t see a bug here, but it’s possible.
Something else affiliated with your update routine is clearing asterisk’s crontab.
These are plain vanilla systems; no third party modules, built from distro.
Maybe whatever malfunction is breaking the scheduled backups is also what’s breaking the LE cert renewals. Just found another system with an expired LE cert that renewed manually without problem.
I have seen both complaints (backup schedules lost, LE renewals broken) but have not experienced either of them. Plain vanilla? Something must be different.
We were seeing the same with S3 backups on most but not all servers. went back in the schedules and resaved them and all OK again.
We did this back in November and all good since.
didnt look further as started working and has since
One of the sites where we found it broken yesterday had broken before, so keep an eye on it. I’m not certain, but it seems to happen during module or core system file updates.
If you have some freedom to experiment, try running
crontab -l -u asterisk
fwconsole ma install backup
crontab -l -u asterisk
Compare crontab outputs and see whether the install script (which runs any time the backup module is upgraded) is affecting your cron jobs.
I’m not a developer or a coder. Call me old-school, but I’d like the coders who work for this developer to test and fix their own code, unless they would like to pay us to do.
As I’ve mentioned here before, we cannot afford to be an unpaid testing department, nor can we, as is almost always requested, provide third parties with unsupervised admin access to systems.
What I know is that these systems were installed from distro and the only third-party module in the mix is from ClearlyIP on a handful.
Let’s say for a moment that the backup and LE stuff works fine for the developers, what kind of fix are you expecting from them without you either performing troubleshooting steps or access to them to do the troubleshooting?
I don’t see anything “old-school” about asking the developers to fix bugs but you have to give them something to work with.
…breaking your system ? Are the developers of said module aware ? What is the output of fwconsole ma list ?
Sorry to rain on your blame parade, but we have (and have had for years) systems without the ClearlyIP modules doing this.
One moment you are going on about accountability, the next you are entirely incorrectly blaming others for your bugs. Please make up your mind.
Because of this type of “support”: It’s not a bug unless you do the work to prove it beyond any doubt, we can’t provide support unless you give us and our third-parties unattended admin access to your systems, we’re closed during your business hours, our commercial module renewals are broken, et al, we are full-stop deploying any additional FreePBX systems.
We experienced very similar behavior in FreePBX 14. Usually, after a system reboot, the backup schedule would simply stop working.
When checking the cron jobs with crontab -l -u asterisk, it wouldn’t return any scheduled tasks at all—even those from other FreePBX modules were missing.
The fix was always to go into the Backup module, edit/resave the backup task, and then run fwconsole reload. Immediately after doing this, crontab -l -u asterisk would correctly list all system tasks again.
We eventually had to set up Zabbix monitoring on the backup logs just to get alerted when this occurred. However, since migrating our systems to FreePBX 17, we haven’t encountered this issue anymore.
Thank you. That’s helps dispense with the usual “No one else has reported this so it must be your fault” response.
This version is EOL and hasn’t been developed or touched in years. This is an improper data point now.
How often is the cronjob going “missing”? I have backups enabled on my system so I’d like to see when this is supposed to happen. Is it every week? Every two weeks? Does it happen if the system just runs untouched? Does it happen after an update is made?
I’m still waiting for the whole “LE certs didn’t renew” issue to hit me. Been running v17 boxes since the beginning of 2025 and the ones I’ve had LE certs on, including my dev system, haven’t had a single issue renewing when needed. It just renewed at the start of the month.
|Issued On|Friday, January 2, 2026 at 8:39:38 PM|
|Expires On|Thursday, April 2, 2026 at 9:39:37 PM|
So how long should one wait before the backup cronjob goes away?
^^^ All of that 
Only seeing it when there is a separate firewall running in between FreePBX and LE 