Track 2 · Lesson 6 of 6
Scheduling work with cron
Use crontab to run a command on a schedule, read the five time fields, and send each run's output to a log you can check.
Cron runs commands for you on a schedule. Instead of remembering to make a backup each evening, you write the job once. Cron then fires it at the times you choose. This lesson sets up a daily job, and shows you how to read back what happened.
What you'll be able to do
- List the jobs you have scheduled with
crontab -l. - Read the five time fields in a cron line.
- Add a daily job with
crontab -e. - Send a job's output to a log file so you can see what it did.
- Use absolute paths, because cron runs with a small environment.
Step 1: See your current jobs
Each user has one crontab, a table of scheduled jobs. crontab -l lists it.
crontab -l
no crontab for u0_a123
That message means you have none yet, which is normal on a fresh Termux install.
Termux does not start cron by default. Install it and switch the service on before any job will fire.
Install the cron package and the service manager.
pkg install cronie termux-services
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
cronie termux-services
0 upgraded, 2 newly installed, 0 to remove.
Then enable the cron service. It prints nothing on success.
sv-enable crond
Step 2: Read the five time fields
A cron line is five time fields, then the command to run. The fields are minute, hour, day of the month, month, and day of the week, in that order. A star means every value.
30 7 * * * command
Read that as minute 30, hour 7, every day of the month, every month, every day of the week. In plain words, 07:30 every morning.
Here are the field ranges:
- Minute: 0 to 59
- Hour: 0 to 23
- Day of the month: 1 to 31
- Month: 1 to 12
- Day of the week: 0 to 6, where 0 is Sunday
A star in the day of the week field means every day. That is what you want for a daily job.
Step 3: Add a daily job
crontab -e opens your crontab in an editor. On Termux that editor is vi unless you have set EDITOR to something else.
crontab -e
The editor opens with an empty buffer. Type your job as a single line, then save and quit. This one runs a backup script at 07:30 every day.
30 7 * * * /data/data/com.termux/files/home/bin/backup.sh
Now list the crontab again to confirm it was saved.
crontab -l
30 7 * * * /data/data/com.termux/files/home/bin/backup.sh
The job is registered. Cron will run it at the next 07:30.
Step 4: Send output to a log
A job that runs in the background has nowhere to print. Any output it produces is either mailed away or lost. Send it to a file instead, so you can read it later. Redirect normal output and errors.
30 7 * * * /data/data/com.termux/files/home/bin/backup.sh >> /data/data/com.termux/files/home/backup.log 2>&1
The >> appends normal output to the log. The 2>&1 sends errors to the same place, so nothing slips past. Read the log whenever you want to check on a run.
tail -n 5 /data/data/com.termux/files/home/backup.log
Backup started at 07:30
Copied 42 files
Archive written to backup-2026-01-31.tar.gz
Backup finished at 07:31
Before you schedule a command, run it once in your terminal with the exact path you plan to use. If it works by hand, you know the command is right and any later failure is about the schedule or the environment, not the command itself.
Step 5: Use absolute paths
Cron does not read your shell startup files. It runs with a minimal PATH, often only the system directories. A command like backup.sh or python may not be found. It works when you type it yourself.
The fix is to write the full path to everything. Compare the two lines below. The first depends on PATH being set up for it.
30 7 * * * backup.sh
The second names the script outright, so PATH does not matter.
30 7 * * * /data/data/com.termux/files/home/bin/backup.sh
The same rule applies inside the script. If it calls python, tar or curl, give each one its full path. Or set PATH at the top of the script.
export PATH=/data/data/com.termux/files/usr/bin:$PATH
Set PATH inside the script itself, not in your crontab. Then the script works the same, whether cron runs it or you do.
Quick reference
| Command | What it does |
|---|---|
crontab -l | List your scheduled jobs |
crontab -e | Edit your crontab in an editor |
crontab -r | Remove your whole crontab |
30 7 * * * cmd | Run cmd at 07:30 every day |
0 * * * * cmd | Run cmd at the start of every hour |
cmd >> log 2>&1 | Append output and errors to a log file |
sv-enable crond | Start the cron service in Termux |
tail -n 5 log | Read the last five lines of a log |
Next steps
- Environment variables and PATH to understand the minimal environment cron provides.
- Archives and compression to make the archive your daily job creates.
- Shell scripting basics to wrap several steps into one script for cron to run.
Test yourself on this
4 questions and 1 task where you run a real command, with the reasoning explained either way.