How to schedule automatic server reboots with cron

Servers can accumulate memory leaks, stale processes and temporary file build-up over time. Scheduling a periodic reboot clears these issues automatically, without requiring manual intervention at unsociable hours.

You will edit the root crontab to add a reboot schedule, confirm the job is registered and check the system logs to verify it ran as expected.

Understanding the crontab format

Cron is a Linux task scheduler that runs commands at times you define. Each line in a crontab file follows a fixed format: five time fields followed by the command to run. Understanding this format lets you adjust your reboot schedule without guessing.

# m h  dom mon dow   command
# |  |   |   |   |
# |  |   |   |   +---- Day of the week (0-7, Sunday = 0 or 7)
# |  |   |   +-------- Month (1-12)
# |  |   +------------ Day of the month (1-31)
# |  +---------------- Hour (0-23)
# +------------------- Minute (0-59)

An asterisk (*) in any field means “every” – so * * * * * runs every minute of every day. For a daily reboot at 02:00, you would use 0 2 * * *.

Schedule an automatic server reboot

The steps below add a cron job to the root user’s crontab. Running the reboot command as root gives it the permissions it needs to restart the system. Using the full path to shutdown prevents cron from failing to locate the command when running in a minimal environment.

1. Open the root crontab for editing.
   Run the following command to open the crontab in your default terminal editor:

sudo crontab -e

2. Add the reboot schedule.
   Scroll to the bottom of the file and add the line below. This schedules a reboot every day at 02:00. Adjust the hour and minute values to suit your requirements.

0 2 * * * /sbin/shutdown -r now

3. Save and exit the editor.
   If your editor is nano, press Ctrl+O, then Enter to save, then Ctrl+X to exit. If your editor is vi or vim, press Esc, type :wq and press Enter. Cron picks up the new schedule automatically.

Your reboot job is now registered. The next section covers how to confirm it is active and how to check that it ran.

Verify the cron job is active

Listing the root crontab confirms your entry was saved correctly. Checking the system logs after the scheduled time confirms the reboot actually occurred.

To list all cron jobs registered for the root user, run:

sudo crontab -l

After the scheduled reboot has passed, check the system log to confirm it ran. On Ubuntu and Debian, run:

grep reboot /var/log/syslog

On AlmaLinux, CentOS or RHEL-based systems, run:

grep reboot /var/log/messages

If you see a timestamped reboot entry in the log, the job ran as scheduled.

Troubleshooting

The cron job did not run

If the reboot did not occur at the scheduled time, the cron service may not be running or the command path may be incorrect.

• Check that the cron service is active: sudo systemctl status cron
• Confirm you used the full path /sbin/shutdown rather than just shutdown.
• Review the cron log for errors: grep CRON /var/log/syslog
• Confirm the crontab entry is saved by running sudo crontab -l and checking your line is present.

The shutdown command failed when run manually

If you want to test the reboot command before relying on cron to run it, you can trigger it directly. This confirms the command works with your current user permissions before the scheduled time arrives.

• Test the command manually: sudo /sbin/shutdown -r now
• If the command is not found, verify the path with: which shutdown
• On some distributions, shutdown may be located at /usr/sbin/shutdown. Update your crontab entry to match.

Wrapping up

You have added an automatic reboot schedule to the root crontab, confirmed the entry is saved and learned how to verify the job ran using system logs. Your server will now reboot at the time you specified without any manual action.

Review your reboot schedule periodically to make sure the timing still suits your traffic patterns. You may also want to log the output of your cron jobs for easier auditing – our guide on how to secure your VPS covers related server hardening steps. For more on working with the Linux command line, see our guides on switching users in Linux and checking open ports on Linux.