Using Scheduled Tasks with Crontab in Linux

A command that works in a terminal may fail under cron because the user, environment, working directory, or permissions differ. Make the task work as a standalone script before assigning a schedule.

Five time fields, then the command

A user crontab lists minute, hour, day of month, month, and day of week, followed by the command. This example is scheduled daily at 03:15:

15 3 * * * /home/app/bin/check-site.sh

System files such as /etc/crontab and commonly /etc/cron.d also include a user field before the command. Do not add that field to a user crontab edited with crontab -e. When both day fields are restricted, common cron implementations use an OR relationship; check your implementation before assuming a particular calendar intersection.

crontab -l
crontab -e

Listing entries does not prove that the scheduler service is running. A new account may have no crontab yet. Save existing entries before editing. Remember that crontab -r removes the user's entire crontab, not just one unwanted job.

A small HTTP check with visible failures

This script belongs to the example app account and only checks an HTTP endpoint. Replace the URL with an endpoint you are authorized to test. Verify the curl path with command -v curl.

#!/bin/sh
PATH=/usr/bin:/bin
export PATH
url='https://example.com/'
if code=$(/usr/bin/curl --fail --silent --show-error \
    --connect-timeout 5 --max-time 20 \
    --output /dev/null --write-out '%{http_code}' "$url"); then
    printf 'HTTP check completed: %s\n' "$code"
else
    result=$?
    printf 'HTTP check failed: curl=%s http=%s\n' "$result" "$code" >&2
    exit "$result"
fi

The script discards the response body, not the error information. It does not follow redirects: a 3xx response may still give curl a successful exit status. If healthy operation requires exactly 200 or a particular response body, validate that separately. Do not add -k to work around certificate errors.

Decide what happens when executions overlap

Prepare /home/app/bin, /home/app/run, and /home/app/log with appropriate ownership and permissions, and make the script executable. Avoid a world-writable shared directory for the lock file. Where util-linux flock is available, this user crontab entry runs every five minutes:

*/5 * * * * /usr/bin/flock -n /home/app/run/check-site.lock /home/app/bin/check-site.sh >> /home/app/log/check-site.log 2>&1

The non-blocking lock skips an execution if the lock is busy; it does not queue the job. Add explicit reporting if skipped runs matter. Arrange log rotation so the output file cannot grow indefinitely. Sending every stream to /dev/null merely hides failures.

Find the stage that actually failed

Run the script as the same user with a minimal environment first. Then inspect the scheduler service, commonly named cron or crond, its trigger records, and the script's own log. A trigger record is not evidence of successful completion. Check disk space and whether the job can write its log directory.

Verify the server time zone. Daylight-saving transitions and downtime need explicit consideration; behaviour depends on the cron implementation. If missed work must run later, choose and configure a suitable timer or queue rather than assuming catch-up behaviour. Percent characters also have special meaning in crontab commands, which is why the curl formatting string lives inside a separate script here. See the crontab format reference.