Why You’re Here: Repeated Commands and Missed Tasks

You log into your VPS, run the same commands again and again, and tell yourself, “I should automate this.”
Then weeks go by, something gets missed, and now you’re cleaning up a mess at 11 PM.

After you set up cron and anacron properly, those boring, repetitive tasks just happen.
Backups, cleanups, reports — they run at the times you choose, quietly in the background.

This guide is for anyone running a Linux VPS (like Ubuntu or other modern distros) who wants a simple, practical way to schedule routine tasks using cron and anacron.
We’ll keep it command-line focused and stick to the basics so you can get from “manual” to “automated” safely.

What Cron Actually Does (In Plain Language)

Cron is a scheduling tool that runs in the background as a daemon.
It starts when your system boots and then just lives there quietly, checking every minute if it needs to do something.

The logic is simple:

• Every minute, cron looks at its configuration files (crontabs).
• If it finds a task that should run at that exact minute, it runs the command you told it to.
• Then it goes back to sleep for another 60 seconds.

Because it checks every minute, cron is flexible.
You can schedule something to run every hour, daily, weekly, or even just once or twice a year.
For a system administrator, it’s one of those basic tools you end up using all the time.

System Crontab vs Your Own Crontab

Cron decides what to run based on files called “crontabs”.
Each crontab lists time rules and the command to run.

There are two general levels:

1. System-wide crontab
2. Location: /etc/crontab
3. Affects system-level tasks.
4. Usually controlled by the OS and packages.
5. The guide source is clear: this file should not be edited in most cases.
6. User crontabs
7. Each user can have their own crontab.
8. Safer and usually the preferred way to schedule your custom tasks.

If you’re just trying to automate things on your VPS for your sites, scripts, or maintenance, you should almost always use your own crontab instead of touching /etc/crontab.
It’s cleaner, safer, and easier to undo.

How to View and Edit Cron Jobs Safely

You work with your own user crontab using a simple command.
This is usually what you want on a VPS.

Step 1: Open your user crontab

Run:

crontab -e

The first time you run this, it may ask you to choose an editor.
Pick the one you’re comfortable with (often nano for beginners because it’s simpler).

This opens your crontab file in the editor.
Each line you add defines one scheduled job.

Step 2: Understand the crontab line format

A cron line has time fields followed by the command.
While the exact formatting details are not fully laid out in the source text, the important concept from the guide is:

• Cron reads these “crontab” entries.
• It checks them once per minute.
• If the time matches, it runs the command.

So the general workflow is:

1. Decide when something should run.
2. Add a line describing that time + the command.
3. Save and exit the editor.
4. Cron will then check that file every minute and act when the time matches.

Step 3: View current cron jobs

To see what’s already scheduled for your user:

crontab -l

This prints your current crontab.
If it’s empty, you’ll see nothing or a simple message.

Basic Safety Tips Before You Rely on Cron

Even though this is “just scheduling,” you can still break things.
Here are some quick safety habits:

1. Test your command manually first
   Run the exact command in your shell before putting it in cron.
   If it fails or behaves strangely when you run it by hand, cron will have the same problem.
2. Use full paths in commands
   Cron doesn’t always have the same environment as your interactive shell.
   Using full paths (/usr/bin/php, /usr/bin/python, etc.) helps avoid “command not found” surprises.
3. Log output somewhere
   If your command supports it, redirect output to a log file.
   This way you can see what actually happened when cron ran it.
4. Avoid editing /etc/crontab unless you know why
   The source explicitly notes this is the system crontab and should not be edited in most cases.
   Use user crontabs instead — much easier to manage and safer.
5. Use correct permissions on any scripts you call
   Make sure the script is executable (chmod +x yourscript.sh) and readable by the user whose crontab you’re editing.

What Anacron Is and When It Helps

Cron is great if your server is always on.
But what if your machine is sometimes off or not running when a job is scheduled?

This is where anacron comes in.
The source guide mentions anacron as the tool you use to make sure tasks still run even when the system is turned off part of the time.

The idea is simple:

• Cron: expects the machine to be on at the scheduled minute.
• Anacron: makes sure periodic tasks still run, even if the machine was off at the exact scheduled moment.

So if you have daily or weekly tasks on a VPS that might reboot or be powered down sometimes, anacron helps catch those missed runs once the system is back.

When to Use Cron vs Anacron on a VPS

The original tutorial uses an Ubuntu VPS as the example, and any modern Linux distribution behaves similarly.
On most VPS setups, the server is on almost all the time, so cron will usually be enough.

Use cron when:

• Your VPS is almost always running.
• You need minute-level or hour-level schedules.
• You’re comfortable with tasks running exactly at set times.

Use anacron when:

• Your system might be off at the scheduled time.
• You still want your daily, weekly, or monthly tasks to eventually run.
• You care more that the task runs at least once per period than the exact minute.

On mixed setups (like laptops or desktops that aren’t always powered on), anacron is especially useful.
On a VPS, it’s more like a safety net for periodic jobs.

Practical Workflow: From Manual Task to Automated Job

Let’s put the concepts together into a simple workflow you can reuse.
We’ll keep it generic because the source text is focused on cron/anacron behavior rather than specific tasks.

1. Identify your repetitive command

Maybe it’s a backup script, a clean-up script, or a report.
Whatever it is, it should already work when you run it manually.

2. Test in the shell

Run your command directly in the terminal.
Fix any errors first — don’t push broken commands into cron.

3. Open your user crontab

crontab -e

This opens your cron configuration for the current user.

4. Add a new job line

Add a line that describes when to run it and what to run.
Cron will then:

• Read this user crontab.
• Check it every minute.
• Run the command if the time matches.

(Remember: exact time-field syntax isn’t detailed in the source text, but the behavior is.)

5. Save, exit, and wait

Save the file and exit your editor.
Cron is already running as a daemon, so you don’t have to restart it.
It will see your new job and start checking for it every minute.

6. Verify later

After the scheduled time passes, check your log output or the result of the task.
If nothing happened, re-check your command, permissions, and paths.

For jobs that must eventually run even if the VPS goes down, make sure your system is using anacron for those periodic tasks.
That way, if the machine was off at the exact scheduled time, the job still runs later.

Quick Recap and Next Step

• Cron runs as a background daemon, checking every minute for tasks to execute.
• It reads crontabs (system and user), and you should usually prefer your own user crontab.
• The system crontab at /etc/crontab should not be edited in most cases.
• Anacron exists to make sure periodic tasks still run even when the system is turned off part of the time.
• Work safely: test commands manually, use full paths, log output, and mind permissions.

With these basics in your pocket, you can start moving your repeated VPS chores into cron and rely on anacron when uptime isn’t excellent.

If this saved you time, bookmark CrushEdge for more fixes.