Web Crons

web-crons.md

I've been thinking about whether it might be easier to use a separate cron file for some of my extension-specific crons and access it over the web, so that I could control the cron schedule on my end without the customer having to worry about configuring it.

I know that running crons over HTTP is generally a bad idea, but I'm just trying to think through the pros and cons.

The main con to having Magento handle this is that many people seem to be running a 5 minute cron, even post-email-queueing, which I don't quite understand. But it is what it is. So now, all of a sudden, in order to enable a feature (order confirmation emails), they're having to go in and update their cron schedule. From a usability point of view, that's quite a bit deeper under the hood than I ever want a customer to have to go in order to enable a feature. If everyone was already running a 1 minute cron, this would make things a lot more seamless, but that just doesn't seem to be the case currently.

Also, I'm concerned that in some cases, increasing the frequency of the cron from 5 minutes to minutely could potentially cause performance issues. While it shouldn't in theory, bearing in mind that any given merchant could have all manner of crazy 3rd party cron situations, I wouldn't be shocked to find that a more frequent cron caused a problem somewhere for someone.

So, the idea of not having to touch their cron setup whatsoever, and just introducing a tight little web cron that I can ping all on my own seems like it could simplify a number of things.

I'm not saying it's a great idea but I'm just asking for feedback on it.

As an extension vendor, you have different constraints than, for example, a solutions parnter. For a solution partner, you always know that you're going to have full control over your hosting environment, that everything will be running smoothly, and if something were to go wrong with a cron, you'd have skilled developers available to troubleshoot it at a handsome hourly rate.

From an extension vendor perspective, you want to make it as easy as humanly possible for the least sophisticated merchant to install and use your software.

What if you change the language/perspective you're approaching it from? Instead of calling it a "cron" you actually just think of it as building an "API endpoint". This API resource does some function (send confirmation emails) when called. It just so happens there's an outside system that periodically calls this API on a scheduled basis.

That might put you in the mindset of building an API that can handle things like rate limiting, authorization and authentication, responses, errors, monitoring and so on. You might be tip-toeing the edges of the current "micro-services" renaissance going on right now.

As a past extension developer, I see where you're coming from. A lot of documentation has even guided customers to scheduling magento crons at 15 minute intervals, which we see a lot. Not good if you're running 1.9 with order confirmation emails queued and customers expecting them right away.

Now I wouldn't actually add some web accessible file you ping like Cron.php. I would add an api endpoint you'll ping. For security you could add an ip whitelist so only you can call it. The problems I foresee from a hosting perspective will be adding to the concurrency of the webserver and the noise you create in logs. Load shouldn't be high hitting it, but people might still be uncomfortable. If either becomes a problem, then ask them to switch to scheduling your cron on a 1 minute interval and stop pinging the api endpoint.

My suggestion is a hybrid approach. For those you don't white glove, ping the api endpoint. And for those who will be uncomfortable by the additional server load or log noise, they will likely be skilled enough to schedule your own cron.

Thanks guys! I don't know why I didn't think about this already, especially given that I already have an API endpoint I could use! Was just a little stuck in the mindset of thinking of it as a cron :)

Appreciate the feedback!

@erichileman totally re: the hybrid approach.