Master Cron Jobs for Website Task Automation

Do you want to wake up at 2 a.m., clear the logs, clean temporary files, and run the same server maintenance tasks every single day?

Well, me neither. Nor do the millions of server admins who manage the 14+ billion servers across the world.

So, stop the madness — I beg you!

Cron jobs are built for that.

Because, genuinely, nothing says “competent sysadmin” like being fast asleep and taking credit for the work your scripts handle for you. It’s called “utilizing your resources.”

With cron jobs:

• Your boss thinks you’re dedicated. 
• Your server knows you’re lazy. 
• You have this beautiful symbiotic relationship called automation. 

Today, you’re going to become a cron jobs pro.

First, What’s a Cron Job? (The Not-Boring Version)

A cron job is essentially a task scheduler built into Unix-like operating systems (Linux, macOS) that lets you run Linux commands automatically at specified times and dates.

Think of it like a to-do list for your server, but…this one actually gets completed.

Cron in Metaphors

If your server infrastructure were a restaurant:

• The cron daemon is the manager checking the daily schedule.
• The crontab is the staff assignment board.
• Each cron job is a task assigned to a specific staff member at a specific time.
• The command is the actual work being done.

When the clock hits the scheduled time, the manager taps the assigned employee on the shoulder and says, “It’s showtime!”

The employee then executes their task without question or complaint.

If only we humans were this reliable, the world would be a different place!

The Anatomy of a Cron Job

Every cron job consists of two main parts:

When to run (the schedule)

What to run (the command or script to execute)

The schedule uses a specific syntax that might look like some computer wizardry at first glance:

But take a closer look and it’ll start to make sense.

Each asterisk can be replaced with specific values, ranges, or intervals to create precisely the schedule you need.

Why Server Admins Love Cron Jobs

There’s a reason why server admins (even me) get misty-eyed when discussing cron jobs.

They turn server management into something that (at least remotely) resembles work-life balance.

1. They Save You Time

Remember time? That thing you never have enough of? Cron jobs give it back. You set them, you forget them, and you’re pretty much never looking at them.

(Well, until they break or you need to change the schedule.)

2. They Maintain Consistency

Humans are inconsistent. We forget things. We make typos. We get distracted by cat videos. Cron jobs perform the exact task, the exact same way, every single time — no exceptions.

3. Your Server Never Sleeps

With cron jobs, essential maintenance happens 24/7/365, whether you’re awake, asleep, or on a beach sipping margaritas.

4. Error Logs > Human Memory

When you manually perform tasks, can you remember exactly what you did and exactly when you did it? Probably not.

But cron jobs can be configured to log their activity, creating a paper trail of all automated actions for troubleshooting and verification.

5. They’re Built for Scalability

As your infrastructure grows, manually managing everything becomes exponentially more difficult. Cron jobs scale effortlessly.

Meaning, the same job can run across multiple servers without requiring additional time from you.

Setting Up Cron Jobs: A Step-by-Step Guide

Enough theory! You need to get your hands dirty with some practical cron job setup.

Step 1: Confirm Cron Is Installed

Most Unix-like systems have cron pre-installed. To check if it’s available for use, type the below command:

crontab -e

Depending on the default editor, the command will open the crontab in your specific editor. If you have never used crontab before, it might ask you to set the default editor.

If the terminal responds with command not found, you’ll need to install cron with the below commands:

• On Ubuntu/Debian: sudo apt update && sudo apt install cron
• On CentOS/RHEL:  sudo yum install cronie

Once done, start and enable the cron service:

sudo systemctl start cron
sudo systemctl enable cron

With the start and enable commands, we’re starting the cron service to execute the cron jobs.

And with enable, we make sure that even if your server restarts, the cron service automatically restarts with it, and no cron jobs are missed.

Nerd Note: CentOS calls the cron service “crond”, so you will need to start and enable the crond service.

Step 2: Understanding the Crontab

Alright, open the crontab or the crontable to begin adding your scheduled jobs.

Each user on the system can have their own crontab file. Additionally, there is a system-wide crontab.

To edit your personal crontab:

crontab -e

This opens your crontab file in your default text editor. If this is your first time, choose the nano editor (option 1) as it’s the most beginner-friendly.

For system-wide crontabs, run the below command with sudo privileges:

sudo nano /etc/crontab

Step 3: Cron Job Syntax

We’ve already talked about the basic structure in the anatomy of cron jobs before.

But creating a cron job can be confusing sometimes. Crontab.guru helps you visualize the job schedules as you type them.

Now for the fun part — writing our first cron job. Let’s take a look at some common cron job schedules:

Every minute:

* * * * /path/to/command

Every hour at minute 0:

0 * * * * /path/to/command

Every day at midnight:

0 0 * * * /path/to/command

Every Monday at 3 a.m.:

0 3 * * 1 /path/to/command

Every 15 minutes:

*/15 * * * * /path/to/command

First day of every month at 6:30 a.m.:

30 6 1 * * /path/to/command

Step 4: Creating Your First Cron Job

Let’s move to creating a simple backup cron job for your server.

The task below creates a backup of your website every day at 2 a.m.

0 2 * * * tar -czf /path/to/backup/website-backup-$(date +%Y%m%d).tar.gz /path/to/your/website

It will output a compressed tar archive of your website directory with the current date as the filename.

Step 5: Save and Verify

Now, exit the editor. In nano, press Ctrl+X and then hit Y.

To view your current crontab and verify your job was added:

crontab -l

That’s it! Your first cron job is now set up and will run automatically at the scheduled time.

Practical Cron Job Examples for Website Managers

Now that you know the basics, let’s explore some practical cron jobs that can make your life as a website manager significantly easier.

Database Backups

MySQL database backup (daily at 1 a.m.):

0 1 * * * mysqldump -u username -p’password’ database_name | gzip > /path/to/backups/db-backup-$(date +%Y%m%d).sql.gz

Log Rotation and Cleanup

Clean logs older than 7 days (weekly on Sundays):

0 0 * * 0 find /path/to/logs -type f -name “*.log” -mtime +7 -delete

Website Performance Monitoring

Check website response time every 5 minutes:

*/5 * * * * curl -o /dev/null -s -w “%{http_code} %{time_total}sn” example.com >> /path/to/logs/website-performance.log

Content Updates

Fetch and update dynamic content (every hour):

0 * * * * /path/to/content-update-script.sh

Email Reports

Send a weekly traffic summary every Monday at 9 a.m.:

0 9 * * 1 /path/to/generate-and-email-report.sh

Security Scans

Run a security scan script every night at 3 a.m.:

0 3 * * * /path/to/security-scan.sh

Cron Job Best Practices: Dos and Don’ts

To make sure your cron jobs run smoothly and don’t cause more problems than they solve, here are some important best practices.

The Dos

Always use full paths to commands and files: Your cron environment doesn’t have the same PATH as your user shell, so “/usr/bin/python” is better than just python.

Redirect output to prevent email spamming: By default, cron emails any output to the user. Add >/dev/null 2>&1 to suppress output or redirect to a log file instead.

Test your commands before scheduling them: Run your command manually to ensure it works as expected.

Add comments to explain each job — Future you will thank present you for documenting what each cron job does and why.

Daily database backup – Added by Jane on 2023-05-15
0 1 * * * /path/to/backup-script.sh

Consider using lockfiles for long-running jobs to prevent a new instance from starting if the previous one is still running.

0 * * * * flock -n /tmp/script.lock /path/to/your/script.sh

The Don’ts

Don’t schedule resource-intensive jobs during peak hours: Your backup doesn’t need to run at noon when your site is busiest.

Don’t use relative paths: “./script.sh” will almost certainly fail in cron.

Don’t forget environment variables: Cron doesn’t load your .bashrc or .profile. Set any required variables in the crontab or script.

Don’t overlook logging: Without proper logging, debugging cron jobs can be a nightmare.

Don’t overdo it: Too many frequent cron jobs can overload your server. Be strategic.

What To Do When Cron Jobs Go Wrong

The only time you have to look back at a cron job is when it breaks — and when it breaks, here’s how to diagnose and fix common issues.

Common Problem #1: Job Doesn’t Run

Symptoms: Your scheduled task doesn’t seem to be executing at all.

Potential fixes:

• Check cron daemon is running: The “systemctl” status cron
• Verify your crontab syntax: Use a tool like crontab.guru
• Ensure full paths to executables: Which command to find full paths
• Check file permissions: Scripts must be executable (chmod +x script.sh)

Common Problem #2: Job Runs But Fails

Symptoms: The job executes but doesn’t complete its task successfully.

Potential fixes:

• Redirect output to a log file to see errors: * * * * /path/to/script.sh > /path/to/script.log 2>&1
• Test the command manually with the same environment
• Check for dependencies that might be missing in the cron environment

Common Problem #3: Email Flooding

Symptoms: Your inbox is flooded with cron output emails.

Potential fixes:

• Redirect output to null: >/dev/null 2>&1
• Redirect to a log file: >/path/to/logfile.log 2>&1

Only email on errors:

* * * * /path/to/script.sh >/dev/null || echo “Script failed” | mail -s “Cron failure” you@example.com

Common Problem #4: Timing Issues

Symptoms: Jobs run at unexpected times or frequencies.

Potential fixes:

• Double-check your timezone settings — date vs. cron’s expectation
• Be aware of DST changes that might affect timing
• Use explicit time frames instead of relative ones when precision matters

Advanced Cron Job Writing Techniques

We’ve looked at the basics, and you are pretty much a pro with cron jobs by now. But this section will take you a step further.

Using Special Strings

You don’t always need to write cron jobs with those asterisk signs. There are some special strings that let you set up cron jobs quite easily.

• @yearly or @annually: Run once a year (0 0 1 1 *)
• @monthly: Run once a month (0 0 1 * *)
• @weekly: Run once a week (0 0 * * 0)
• @daily or @midnight: Run once a day (0 0 * * *)
• @hourly: Run once an hour (0 * * * *)
• @reboot: Run once at startup

For example, if you want something to run daily, just write the below command:

@daily /path/to/daily-backup.sh

Environment Variables in Crontab

To avoid repeating a string over and over again in your cron jobs (for example, a specific path, or your admin email), set up environment variables at the beginning of your crontab. 

You can then reuse the variables as required within your scripts or commands.

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=admin@example.com

# This job will send errors to admin@example.com
0 2 * * * /path/to/mailing_script.sh

If we use the environment variable MAILTO in our mailing_script.sh, the script will automatically send an email to the correct email address.

With this, changing the admin email will only require changing the value of the MAILTO variable, instead of making changes across all scripts.

Running Jobs As Different Users

If you have superuser access, you can edit another user’s crontab:

sudo crontab -u username -e

Using Anacron for Machines That Aren’t Always On

Unlike cron, anacron ensures jobs run even if the computer was off during the scheduled time:

sudo apt install anacron

Edit /etc/anacrontab to add jobs that will run when the system comes back online.

Job Chaining for Complex Workflows

Run jobs in sequence:

0 1 * * * /path/to/first-script.sh && /path/to/second-script.sh

Monitoring Cron Jobs 

For serious server management, consider tools like Cronitor that provide monitoring and alerts for your cron jobs.

0 * * * * cronitor exec check-12345 — /path/to/your/script.sh

Let’s Talk Costs

Cron jobs can’t exist in isolation. They need a server and a service running on a server that you need to manage. 

Now, if you’re reading this article, it’s highly likely that you have a server for your website or application. 

In fact, if you’re hosting with DreamHost VPS or any Linux-based hosting provider, you’ve already got everything you need to get started with automating your server management tasks. 

If not, a $10/month VPS is all you’d need, especially when starting out. 

For those already running a DreamHost VPS, the process couldn’t be more straightforward:

SSH into your server

Run crontab -e to edit your personal cron table

Add your scheduled tasks

Save, and let the automation begin!

That’s it. The infrastructure you’re already paying for suddenly becomes more valuable, more efficient.

Your Server’s New Autopilot

Congratulations! 

You’ve graduated from manual labor to automation wizardry. With cron jobs handling the routine maintenance, backups, and monitoring, you can focus on growing your website and business rather than babysitting the server.

And remember, it’s going to be a process. The automation will become more sophisticated as you add more and more tasks to it. 

But for now, start with a few essential cron jobs, monitor how they perform, and gradually expand your automation as you grow more comfortable with the process.

Now go on and take that nap, because you just saved yourself a buttload of time.