Cron Job Not Running After Server Reboot — Fix Guide

Server reboots happen — planned maintenance, kernel updates, power outages, cloud provider restarts. When your server comes back up, your cron jobs should resume automatically. If they don't, one of these issues is the cause.

1. The Cron Service Isn't Enabled on Boot

This is the most common cause. The cron daemon needs to be both running and enabled (set to start automatically on boot). These are two separate things.

Check the status:

# Check if cron is running right now
systemctl status cron

# Check if cron is enabled to start on boot
systemctl is-enabled cron

If the output of is-enabled shows disabled, cron won't start after a reboot.

Fix it:

# Start cron right now
sudo systemctl start cron

# Enable cron to start on every boot
sudo systemctl enable cron

On CentOS, RHEL, and Amazon Linux, the service is called crond:

sudo systemctl start crond
sudo systemctl enable crond

On older systems without systemd, use:

# SysVinit
sudo service cron start
sudo update-rc.d cron defaults

# Or on CentOS/RHEL
sudo chkconfig crond on

2. Your Crontab Was Lost

In rare cases, a crontab can be lost after a reboot — typically due to an OS upgrade, filesystem corruption, or if crontab files were stored on a temporary filesystem.

Check it:

# List your current crontab
crontab -l

If you see "no crontab for [user]" or the entries are missing, your crontab was lost.

Where crontabs are stored:

# User crontabs are typically in:
ls -la /var/spool/cron/crontabs/    # Debian/Ubuntu
ls -la /var/spool/cron/             # CentOS/RHEL

Prevent future loss: Always keep a backup of your crontab:

# Back up your crontab to a file
crontab -l > ~/crontab-backup.txt

# Restore from backup
crontab ~/crontab-backup.txt

Better yet, version-control your crontab entries. Store them in your project's git repository and apply them during deployment:

# In your deploy script:
crontab /path/to/project/crontab.txt

3. Using @reboot Jobs Correctly

Cron supports a special @reboot directive that runs a command once when the cron daemon starts (which typically happens at boot time). This is useful for starting background services or running initialization scripts.

# Run a script once at boot
@reboot /home/user/scripts/start-service.sh

# Run with a delay to let other services start first
@reboot sleep 30 && /home/user/scripts/start-service.sh

Common @reboot pitfalls:

• @reboot depends on cron being enabled. If the cron daemon doesn't start on boot, @reboot jobs won't run either. Always ensure systemctl enable cron is set.
• Network may not be ready. At boot time, network interfaces may not be configured yet. If your script needs network access, add a delay or check for connectivity first.
• Filesystems may not be mounted. NFS mounts and other remote filesystems might not be available immediately at boot.
• Environment is minimal. Like regular cron jobs, @reboot jobs run with a minimal environment — no PATH, no shell profile loaded.

A robust @reboot entry:

@reboot sleep 60 && /usr/bin/bash -l -c '/home/user/scripts/start-app.sh >> /var/log/start-app.log 2>&1'

This waits 60 seconds for services to settle, uses bash with a login shell for environment variables, and logs all output.

4. Crontab Lost After OS Update

Major OS updates (e.g., upgrading from Ubuntu 22.04 to 24.04) can sometimes reset or remove crontab files. This is rare but devastating when it happens.

Diagnose it:

# Check if crontab exists
crontab -l

# Check the raw crontab file
sudo ls -la /var/spool/cron/crontabs/
sudo cat /var/spool/cron/crontabs/$USER

Prevent it:

1. Always back up crontabs before OS updates: crontab -l > ~/crontab-backup-$(date +%Y%m%d).txt
2. Store crontab entries in version control (git)
3. Use configuration management tools (Ansible, Chef, Puppet) to define cron jobs declaratively
4. Use /etc/cron.d/ drop-in files instead of user crontabs — these are managed files and are less likely to be lost

5. Docker Containers Losing Crontab on Restart

If you're running cron inside a Docker container, the crontab is lost every time the container is recreated (which happens on restart if you're not using a volume). This is a very common issue in containerized environments.

The problem: Docker containers are ephemeral. When a container stops and restarts, any changes made inside the container (including crontab -e) are gone unless they were part of the image or a mounted volume.

Fix option 1: Install the crontab in your Dockerfile:

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y cron

# Copy crontab file
COPY crontab /etc/cron.d/myapp-cron
RUN chmod 0644 /etc/cron.d/myapp-cron
RUN crontab /etc/cron.d/myapp-cron

# Create log file
RUN touch /var/log/cron.log

# Start cron in the foreground
CMD cron && tail -f /var/log/cron.log

Fix option 2: Mount the crontab as a volume:

# docker-compose.yml
services:
  app:
    image: myapp
    volumes:
      - ./crontab:/etc/cron.d/myapp-cron:ro

Fix option 3: Use the host's cron to run commands inside the container:

# On the host's crontab:
*/5 * * * * docker exec myapp-container /path/to/script.sh

This is often the simplest and most reliable approach — the host's cron daemon persists across container restarts.

6. Verifying Cron is Working After a Reboot

After fixing the issue, verify that cron is properly configured to survive a reboot:

# 1. Check cron is enabled
systemctl is-enabled cron    # Should show "enabled"

# 2. Check cron is running
systemctl is-active cron     # Should show "active"

# 3. List your crontab
crontab -l

# 4. Check cron logs
journalctl -u cron --since "today"

# 5. Add a quick test job
crontab -l | { cat; echo "* * * * * echo 'cron-test-$(date)' >> /tmp/cron-test.log"; } | crontab -

# Wait 2 minutes, then check:
cat /tmp/cron-test.log

# Remove the test job when done
crontab -e

---

Know When Cron Stops After Any Reboot

Reboots are unpredictable — kernel panics, cloud provider maintenance, power outages. You won't always be there to manually verify that cron resumed. CronSignal monitors your cron jobs and alerts you the moment a scheduled heartbeat is missed.

Add a ping to each critical job:

0 2 * * * /home/scripts/backup.sh && curl -fsS https://api.cronsignal.io/ping/your-check-id

If the server reboots and cron doesn't come back up, CronSignal notices the missing ping and alerts you — before you realize anything is wrong.