How to check cronjob is working for laravel app in digital ocean server?

Stefan Bogdanescu

Founder & Senior Architect · 2026-06-29

Laravel Company

How to Check Cronjobs Working for Your Laravel App on DigitalOcean? A Developer's Guide

Setting up scheduled tasks—or cron jobs—is a fundamental part of modern application development, especially when dealing with background processing in frameworks like Laravel. When deploying a Laravel application on a server like DigitalOcean using Ubuntu, you rely on the operating system’s scheduler (cron) to execute your PHP Artisan commands regularly.

The challenge often lies not just in setting up the cron entry, but in reliably verifying that the execution actually happened and succeeded. As a senior developer, we need methods that are fast, accurate, and provide clear feedback.

This guide will walk you through the most effective, developer-focused ways to check if your Laravel scheduler is running correctly on your DigitalOcean server.


Understanding the Laravel Scheduling Mechanism

In a Laravel application, scheduling is managed by the schedule:run command, which executes the tasks defined in your app/Console/Kernel.php. This command itself is typically executed periodically via the system's crontab.

Your setup involves two layers:

  1. Laravel Layer: Defining what needs to run (e.g., sending emails daily).
  2. OS Layer (Cron): Defining when the Laravel command should be executed (php artisan schedule:run).

If the cron job runs, but the PHP script throws an error or fails silently, you won't know until the data is missed. Therefore, checking the execution requires looking beyond the crontab file itself and into the system logs.

Method 1: Checking System Logs (The Direct Approach)

The most immediate way to see if a command was attempted is by examining the system logs. On Ubuntu servers, these logs are typically managed via syslog or the modern journalctl.

You can use commands like grep to filter the system log for entries related to your cron execution time. For example, if you run the job at 9:00 AM, you would check the logs around that time.

# Check recent system logs for PHP or cron activity
sudo grep 'php artisan schedule:run' /var/log/syslog

Pros: Simple and requires no code changes.
Cons: It only confirms that the command was initiated. It does not confirm that the Laravel application successfully handled the task, meaning it doesn't catch fatal PHP errors within the job itself.

Method 2: Implementing Robust Logging (The Best Practice)

For true verification, you must make your scheduled tasks self-reporting. Instead of relying solely on system logs, integrate logging directly into your Artisan commands or scheduled jobs. This is a best practice for any production application, promoting transparency and easier debugging.

You can modify how the command runs to output its results to a dedicated log file, which you can then inspect easily.

Example: Redirecting Output for Verification

When setting up your crontab entry, ensure you redirect all standard output (stdout) and standard error (stderr) to a specific log file rather than /dev/null. This forces the command's output into a persistent file on the server.

Original (Silent):
* * * * * * php /var/www_testing/artisan schedule:run >> /dev/null 2>&1

Improved (Logging):

* * * * * * php /var/www_testing/artisan schedule:run >> /var/log/laravel_schedule.log 2>&1

Now, after the scheduled time has passed, you can simply check this log file to see exactly what the command produced:

cat /var/log/laravel_schedule.log

If the log file is empty or contains specific error messages (like a fatal PHP error), you immediately know where the failure occurred. This approach aligns perfectly with robust application design principles, much like ensuring data integrity when dealing with background processes in Laravel.

Conclusion: Ensuring Reliability

Checking cron jobs is less about finding a magic button and more about establishing reliable observability. Never rely solely on the system scheduler to confirm application logic execution. By combining system log checks (Method 1) with explicit output redirection and logging within your scheduled tasks (Method 2), you create an ironclad verification process. This methodology ensures that whether a job succeeds or fails, there is an auditable record of the attempt, allowing you to maintain stability in your DigitalOcean environment.