As of today, the 9th August 2023, the Cron Jobs feature is disabled.
In collaboration with iFastNet, we have determined that a large number of cron jobs were running a very frequently on invalid URLs, or sites that were not actively being used. This resulted in a lot of server power being spent on cron jobs that didn’t work, or were running on sites that were not actively being used. This had gotten so bad that some cron jobs dramatically overloaded some servers causing performance degradation for many other sites.
We have weighed the options and have looked for ways we could continue to offer cron jobs for the websites where it actually is useful without wasting sever power unnecessary. But we have come to the conclusion that there is simply no way to reliably determine this. Because of this, any automated background periodic requests are now prohibited on free hosting.
The Cron Jobs feature in the client area will be dismantled over the next few hours/days, and the cron jobs feature in the control panel will be disabled and remove too. Please do not try to find alternatives, any attempts to reproduce this functionality will be blocked.
We’re sorry that we cannot offer this feature anymore. We are well aware that there are many legitimate reasons to use cron jobs and we regret that we cannot support these use cases anymore.
If your website requires cron jobs, please consider switching to premium hosting, which does still provide full cron job functionality, including full control over the schedule, and support for running both web crons and PHP commands.
Like @wackyblackie said. It might be a “victim of it’s own success” type of situation. Cron job feature in the control panel was hard to use so many people skipped it. Then the InfinityFree version got added, which was a lot easier to use, so a lot more people used it. And misused it, apparently.
Disabling the functionality on our end, and then condoning the use of other solutions that have the same effect, is not the kind of functionality gate keeping we want to do.
No, not really. From what I can see the cron jobs do stopped working at Aug 9, 15:00 UTC, after that the cron continued to run for a while (around 1 hour) but all throws out 403. After that period I can no longer see new outputs. The reason why it is still there was most probably because the Admin hasn’t removed it yet.
I am kinda confused by this, does that mean uptime monitoring services are now prohibited on Free Hosting?
Like, if an uptime monitoring sends a request to our website, a PHP script can also be executed.
In the article you mentioned that the reason of the Cron Jobs removal is because server power is wasted on useless URLs, which if we use an uptime monitoring service, it could eliminate the need of automation on InfinityFree/iFastNet’s servers, but still allowing legitimate users to be able to use a similar feature.
I’m not sure about iFastNet’s cron jobs, but the InfinityFree cron jobs (which are 100% custom by the way) already store the status code, and I had plans to build something that automatically disables cron jobs that don’t work. I told iFastNet about this and was willing to expedite this, but they were very clear that there were no conditions under which they were willing to accept cron jobs.
I’m aware. Patience please, I’ve been busy but I intend to get started with the proper teardown tomorrow.
Yes, all the client area buttons are still there, but the dispatcher that actually schedules the cron jobs to be executed has been disabled. It will be removed soon.
Good question! I’m not sure about this one.
Uptime checkers can still check if the server responds, but they will be happy if they just see the browser validation challenge. For a cron job to work, you’d need something to break past the Javascript challenge.
That also means that you cannot use an uptime checker to make a poor man’s web cron: the uptime checker wouldn’t actually trigger any code on your site.
So uptime checkers are safe enough to try for their intended purpose. But they won’t work as a cron job replacement.
So for this, and all other “but can I do…” questions: no, you cannot do it. It’s either technically not possible, and if it is technically possible, it’s not allowed and will be blocked if we find you are doing this.
If we wanted people to have cron job like functionality, we would be changing the feature so it conforms to the rules, not removing it entirely.
To be clear: the problem is the load it generates on the server side, i.e. on the sites being triggered by the cron jobs. Triggering the URLs is the easy part. The InfinityFree version of it worked really efficiently, and because it’s entirely built on the InfinityFree side, requires zero effort to run or maintain for iFastNet.
