Schedule Tasks in Laravel and Debug Them
Subscribe to my newsletter and never miss my upcoming articles
Automated tasks has existed on many platforms for a long time. The purpose can be many, but in web applications it's often to optimise speed for the user on heavy duties by caching results.
It can also be used to perform various maintenance tasks to easen administration. You can think of Windows Update that runs in the background.
If you, like most people, are running Laravel on Linux, ie Ubuntu, it's important to understand the basics of cron in order to understand how task scheduling works.
A brief summary of the terminology
A scheduled task in cron is called a cron job.
All your cron jobs are stored in a table this is shortened to crontab (cron table).
On Linux you can edit the table with
cron -e or list the entries with
Syntax and interval
The syntax for a cron job in the crontab is:
The interval is defined by 5 numbers:
- Day of month
- Day of week
Asterix (*) is used to define an any paramater. If you want to run a command every minute it's simply:
* * * * * command
I will not go further into the intervals, but you can generate your own at sites like crontab-generator.org
Laravel task scheduling
It's important to understand the concepts of cron as Laravels task scheduling is tightly coupled to it. For example look at the first method described in the documentation:
->cron('* * * * *');
The rest of the methods are basically syntactic sugar to help you maintain more a readable code.
Laravels task scheduling is in fact not scheduling in itself. It's constructed so you run a cronjob every minute against Laravel which then checks its internal table to see if any commands are due to execution. This is important to know, if you want to investigate why your scheduled tasks are not running, it might be the cronjob is missing or not working.
The cronjob for Laravel is (
* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1
You should add this cronjob in
www-data (or what other name your web user has) in order to retain proper permission on files.
As mentioned earlier caching is a situation where you can benefit from background tasks. An example from my own experience is where we have a pivot table. A pivot table is a useful tool if your clients needs to lookup data in many different ways with filters, customised output and so on. However, since the data come from across the whole application and the tables have several thousands of records, it's not a few seconds job to collect the data.
Instead we have set up task scheduling to cache this whole output every 15th minute (
->everyFifteenMinutes();) so with a slight delay the users can load the pivot table in a few seconds instead of minutes.
Another useful situation is when you want to perform maintenance jobs, but don't want to have to click a button every day to execute the maintenance script.
You might have implemented GDPR and added a feature where users have the right to be forgotten. You might also leave a door open, so that they can cancel the process within 14 days. This means when they request deletion you mark them with a timestamp
deletion_request_at, after 14 days, if not nulled, they will be removed.
You could set a task to run every midnight (
->daily();) to check if any such users has passed 14 days.
Debug task scheduling
A common issue with scheduled tasks, since they are performed in the background, is that it can be difficult to monitor if they are running at all and when they are failing it can be even more difficult to understand what went wrong.
For that reason I created a Task feature in CloudMonitor that will not just monitor if your scheduled tasks are running as expected, but will also show you the output so you know what exactly went wrong.
A log history allows you further to learn if it's the same error that is happening every time or they differ. It could be sometimes a remote service don't respond and other times your memory is exhausted, etc.
CloudMonitor.dk – Free Laravel Maintenance- and Bug Management