Kevin Schroeder has a post to his site sharing some helpful tips for monitoring Magento jobs and crons to help provide a bit more information about the job and its current state.

About a month ago a client of mine was lamenting the fact that they didn’t have insight into what was going on with their cron jobs. So I did what any idiot would do and built out a service that does just that. It works with any Magento version, 1 or 2, system crons, and you can use an API to integrate it with your own system with a very minimal amount of work. I call it the 10n Job Health Vault. With Magento 1 or 2 you can have it set up and running in under 5 minutes (minus DI compilation time, of course).

The tool tracks the execution of the job and notifies you if something's wrong and it hasn't finished. This also means it can track the execution time and report back if it's slower than usual. You can find out more information about this Magento monitoring tool on its website.

Cal Evans has posted the second part of his series as he works through the installation and configuration of the Mautic PHP-based marketing automation tool. In this part of the series he focuses on cron jobs.

This time we are talking about the cron jobs necessary to make Mautic run. Mautic has several commands that are necessary to execute that are not web based. They are run from the command line manually (dumb idea) or using a scheduler like cron on Linux. As with my “Installing Mautic” post, this post is only interesting to those of you self-hosting Mautic.

There is a great manual page on this titles “Cron Jobs”. It tells you a lot of what I’ll tell you here. If you haven’t read it yet, I highly recommend you start there.

He talks about each of the four jobs that, if you're using the system yourself, will want to run often: one for handling segments, two for campaigns and another for sending messages. He also talks about the main problem he ran into during his work with the cron jobs - permissions issues. He shares how he resolved this issue with an extra line in his crontab (after changing the user they ran as) and ends with some extra advice against wide open permissions.

TutsPlus.com has posted the latest tutorial in their "Programming with Yii2" series showing you how to work with cron services to periodically run scripts in your application.

In this Programming With Yii2 series, I'm guiding readers in use of the Yii2 Framework for PHP. In today's tutorial, I'll share with you how to take advantage of Yii's console capacity to run cron jobs.

In the past, I've used wget in my cron jobs—a web accessible URL would run my background tasks. This raised security issues and has some performance problems. While I addressed some ways to mitigate risks in our startup series' episodes on security, I had hoped to transition to console-driven commands. And with Yii2 it's fairly straightforward.

He starts with a brief look at what a "cron" is for those that may not be familiar and how it works on linux-based systems. He then gets into the use of console "cron" commands using the Yii2 framework's own functionality to create a "cron controller" that performs Twitter operations on "frequent", "quarter" and hourly measurements. He shows how to update the crontab file to call the commands instead of making the web requests. He ends this tutorial with an issue to consider regarding different namespaces when using the commands versus web requests.

Edd Mann has written up a tutorial for the MyBuilder.com Tech blog about managing background processes in a Symfony application with the help of Supervisor.

When a web application reaches a sufficiently large size, it can become infeasible to perform all actions required within a single web request/response life-cycle. You may find yourself wishing to for example - batch up and send queued emails at particular intervals, or process payments asynchronous to the point in-time the user made the initial request. In this post I would like to discuss our changing use of background processes (both time-dependent and continuous) due to increasing throughput demands.

He starts out with the first approach most applications take when needing to run automated, asynchronous processes - cron. Using it and a custom bundle they created for it, Edd shows how to directly integrate the cron timing of commands into the class attributes. However, after a while the system grew and it needed something a bit more powerful than cron, something that could correctly handle long running processes. Ultimately they decided on Supervisor, a processes manager and control system that makes managing these processes simpler. He talks about the transition they made from cron over to Supervisor (safely) and how they integrated the signaling functionality Supervisor allows into their application.

On the Zend Developer Zone there's a new post talking about scheduling in applications ("scheduling elePHPants") including both library recommendations and advice about code reuse.

It was while I was creating the 100th or so cronjob to do some very similar to the other 99 that I thought, “Hey! Why not just put all this in a database and check it once a minute instead?” [...] It would be so much easier to deal with in PHP. Also, cron does not scale well at all either in performance or management.

The problem is that cron is an elegant solution for “Do this at that time” type of problems. Every solution I came up with was basically re-creating cron. That in itself isn’t a bad thing, but the logic involved in doing what cron does is mind-melting.

[...] Then it hit me, I am probably not the first person that has had this need. There have probably been other people who needed to implement “Do this at that time” within a PHP application. So I started looking around. What I found was encouraging.

The author then mentions several packages that he went through searching for the right solution to his problem, noting that while Laravel-based solutions seemed nice, they wouldn't work with his framework choice (Slim). He decided on the cron-expression package, finding it to be the best fit for the project's needs.

I had spent countless hours trying to create the solution myself. [...] I got so lost in solving the problem, I forgot to look to see if someone had already solved it. [...] After I finally came to my senses, I tweeted that out to remind myself to “Use the Source”.

The SitePoint PHP Blog has a new tutorial posted from author Reza Lavaryan showing you how to use the Crunz package to make cronjobs a bit simpler in a more framework-agnostic way.

In this article, we’re going to learn about a relatively new job scheduling library named Crunz. Crunz is a framework-agnostic library inspired by Laravel’s Task Scheduler, but improved in many ways. [...] Before getting started, you should have a firm grasp of cronjobs, so please read our in-depth walkthrough if you’re unfamiliar with how they work.

The tutorial then starts in on the code, getting the library installed and setting up a basic task example. The "task" files are sets of cron-formatted commands that are read and executed much like the cron daemon would on a Unix-based system. Example code for a task and command are included. They also talk about the "frequency" settings allowed by the library and the helper methods to make creating them simpler. The post also includes details about task lifetime, running conditions, configuration and parallelism (among other topics).

If you've ever wanted to learn about cron jobs, how to set them up and what kind of functionality they provide then the SitePoint PHP blog has the post for you. In this comprehensive guide to cron you learn about these topics and more.

There are times when there’s a need for running a group of tasks automatically at certain times in the future. These tasks are usually administrative, but could be anything – from making database backups to downloading emails when everyone is asleep. [...] This article is an in-depth walkthrough of this program, and a reboot of this ancient, but still surprisingly relevant post.

They start by going through some of the basic terminology and syntax, where the cron files live and what a typical file format looks like. Also included are instructions on:

• how to edit the cron correctly (crontab)
• the structure of each cron entry
• how to have it run at the time you want
• editing another user's crontab
• cron permissions
• redirecting output

They also talk about executing PHP in a cron job, how to prevent overlaps with a "lock" file . There's also a mention of Anacron as a replacement for cron and a few helpful hints to help you debug when things go wrong.

On the SitePoint PHP blog Daniel Sipos has written up a tutorial spotlighting a powerful feature of Drupal 8, the latest major release of this popular project: the Queue API. Queueing in Drupal allows you to offload tasks to be handled outside of the current web request.

The Queue API in Drupal allows us to handle a number of tasks at a later stage. What this means is that we can place items into a queue which will run some time in the future and process each individual item at that point and at least once. Usually, this happens on CRON runs, and Drupal 8 allows for a quick set up for cronjob based queues. It doesn’t necessarily have to be CRON, however.

They use two examples to help illustrate how to use the queueing system: one that uses the cron-based approach and another that's more manually triggered. They start out with the theory behind it all, talking about the different pieces (objects/classes) and how they fit together to make the queueing system. With that out of the way the article starts in on the code and the "Node Publish" queue, defining its basic structure and hooking it in to the framework. It shows you how to create the cron worker to process the queue and how to build the manual worker to do the same but only when specifically called.

In a post to his site Leonid Mamchenkov shares an interesting output bug he came across in his work developing cron jobs and how they handled his errors.

We came across this PHP bug at work today. But before you go and read it, let me show you a use case. See, if you can spot the problem. We had a cron job script which [ran a PHP script and echoed a string when complete].

[...] We use similar code snippets all over the place, and they work fine. This particular one was a new addition. So the cron job ran and “Updating products failed” part happened. Weird. The PHP script in question has plenty of logging in it, but nothing was logged.

After adding more and more logging to the process and PHP script, nothing obvious was standing out. Finally, they noticed that the filename was incorrect but normally that would cause an error in the PHP command line execution. The tricky part here was in how PHP handled its errors. Their error_log and display_errors settings were such that the PHP "missing file" error was being swallowed up and not displayed.

If you've ever worked with the "cron" tool on a unix-based system, you know that there's a special syntax that comes along with defining when the commands should run. It can be difficult to get this timing exactly right, especially if you're very picky about the execution time. In this post from Sameer Borate he shows you a PHP library that can help not only parse current cron configurations but also provides shortcuts for common timings (ex: "daily" or "weekly").

Working with cron scheduling can many times be a frustrating affair. Although setting a few cron jobs at one time can be easy, calculating cron dates in the future in code can get time consuming quickly. The PHP cron expression parser described here can parse a CRON expression, determine if it is due to run, calculate the next run date of the expression or calculate the previous run date of the expression. You can calculate dates far into the future or past by skipping n number of matching dates.

He includes some examples of putting the library to use to define a cron object based on an expression (either via a shortcut or an actual cron time expression). You can then check to see if the cron is "due" or perform some various operations about its run dates. This includes a formatted output of the previous run time, the next run time and the calculation of the next/previous run time based on a relative timestamp.