Read and write schedules for reports and backups that run while you get on with your day.
PrivateNo uploadsRuns in your browser“Every 15 minutes, every hour from 09:00 to 17:59, Monday to Friday”
Cron uses the clock of the machine it runs on. UTC never changes for daylight saving.
…
| Minute | */15 | 0, 15, 30, 45 |
|---|---|---|
| Hour | 9-17 | 9, 10, 11, 12, 13, 14, 15, 16, 17 |
| Day of month | * | every |
| Month | * | every |
| Day of week | 1-5 | Mon, Tue, Wed, Thu, Fri |
Syntax: * any, 1-5 range, */10 step, 1,15 list, @daily macros. A leading seconds field is ignored.
One operator per step, with examples you can run and a task checked as you type.
0 of 8 done
Step 1 of 8
A cron schedule is five values separated by spaces, always in the same order: minute, hour, day of month, month, day of week.
A star means “every”. So five stars is every minute of every hour of every day. Put a number in a slot to pin it.
“Every minute”
Every minute
Run at 30 minutes past every hour.
Look things up by topic. The authoritative text is the crontab(5) man page, or man 5 crontab on your own machine, which describes the exact cron you are running.
┌──────── minute (0-59) │ ┌────── hour (0-23) │ │ ┌──── day of month (1-31) │ │ │ ┌── month (1-12 or JAN-DEC) │ │ │ │ ┌ day of week (0-7 or SUN-SAT, 0 and 7 = Sunday) │ │ │ │ │ * * * * * [user] /path/to/command arg1 arg2
Five fields, then the command. System crontabs (/etc/crontab and /etc/cron.d) take a user name between the two. Both 0 and 7 mean Sunday. When day of month and day of week are both restricted, the job runs when either matches.
| Field | Values | Allowed |
|---|---|---|
| Minute | 0-59 | * , - / |
| Hour | 0-23 | * , - / |
| Day of month | 1-31 | * , - / ? |
| Month | 1-12 or JAN-DEC | * , - / |
| Day of week | 0-7 or SUN-SAT | * , - / ? |
| Character | Meaning | Example |
|---|---|---|
| * | Every value | * in the hour field: every hour |
| , | List | 1,15 in day of month: the 1st and the 15th |
| - | Range | 9-17 in hour: 09:00 to 17:00 inclusive |
| / | Step | */10 in minute: every 10 minutes; 5/10: every 10 minutes from :05 |
| ? | Same as * here | Quartz uses it for “no specific value” in day fields |
| @macro | Whole schedule | @hourly, @daily (@midnight), @weekly, @monthly, @yearly (@annually) |
| Macro | Equivalent | Runs |
|---|---|---|
| @hourly | 0 * * * * | Top of every hour |
| @daily, @midnight | 0 0 * * * | Every day at 00:00 |
| @weekly | 0 0 * * 0 | Sunday at 00:00 |
| @monthly | 0 0 1 * * | 1st of the month at 00:00 |
| @yearly, @annually | 0 0 1 1 * | 1 January at 00:00 |
| @reboot | — | Once when the daemon starts; not a schedule, so not parsed here |
Click one to load it into the parser.
| Every minute | |
| Every 5 minutes | |
| Every hour, on the hour | |
| Every 6 hours: 00:00, 06:00, 12:00, 18:00 | |
| Every 6 hours, Monday to Friday only | |
| 09:30 on weekdays | |
| Every half hour during office hours, weekdays | |
| 22:00 on weekdays | |
| Midnight every day | |
| 04:05 every Sunday | |
| Midnight on Saturday and Sunday | |
| Midnight on the 1st of every month | |
| 14:15 on the 1st of every month | |
| Midnight on the 1st and 15th | |
| Quarterly: 1 Jan, 1 Apr, 1 Jul, 1 Oct | |
| Once a year, 1 January | |
| 09:00 on Mondays in the first quarter |
Most servers already have cron. Install it where it is missing, make sure the daemon is enabled at boot and running now, then prove it with a one-line job.
| System | Install | Enable and start | Check |
|---|---|---|---|
| Debian, Ubuntu | sudo apt update && sudo apt install cron | sudo systemctl enable --now cron | systemctl status cron |
| RHEL, Rocky, Alma, Fedora | sudo dnf install cronie | sudo systemctl enable --now crond | systemctl status crond |
| Arch | sudo pacman -S cronie | sudo systemctl enable --now cronie | systemctl status cronie |
| Alpine | Built into BusyBox, nothing to install | rc-update add crond && rc-service crond start | rc-service crond status |
| macOS | Preinstalled; launchd is Apple's own scheduler | Starts on demand once a crontab exists | pgrep -l cron |
| Docker image | apt-get install -y cron (or cronie) | CMD cron -f (foreground, as PID 1) | docker exec <ctr> pgrep cron |
# Is the daemon running, and will it start at boot? pgrep -a cron # any system: prints the pid and command, nothing if not running systemctl is-active cron # systemd: active or inactive (crond on the Red Hat family) systemctl is-enabled cron # systemd: enabled or disabled service cron status # older init systems # Start, enable at boot, or restart after editing /etc/crontab or /etc/cron.d sudo systemctl start cron sudo systemctl enable cron sudo systemctl restart cron # not needed after crontab -e: cron notices that itself # Watch it work journalctl -u cron -f # or: tail -f /var/log/syslog | grep CRON * * * * * date >> /tmp/cronlog # a one-line job; if this file grows, cron is fine
| Topic | Note |
|---|---|
| Who may use it | If /etc/cron.allow exists only the users listed in it can have a crontab. Otherwise anyone not in /etc/cron.deny can. Both files hold one user name per line. |
| macOS privacy | Since macOS Mojave a cron job that reads protected folders such as Documents or Desktop needs Full Disk Access granted to /usr/sbin/cron under System Settings, Privacy and Security. |
| Containers | Images do not ship cron. Install it, copy a crontab into /etc/cron.d, and run cron -f as the container's main process so the container stays alive. |
| Time | Cron trusts the system clock. Check date and timedatectl, and keep NTP on. A wrong zone shifts every job by hours. |
A crontab holds blank lines, comments starting with #, variable declarations and job lines. Nothing else. Variables are written NAME=value with no export, and apply to the jobs below them. Cron reads the file once a minute and re-reads it when the crontab command saves a change.
| Variable | What it does | Example |
|---|---|---|
| PATH | Where cron looks for commands given without a full path. Cron's default is tiny, so scripts found from your terminal are often “command not found” under cron. | PATH=/usr/local/bin:/usr/bin:/bin:/home/deploy/bin |
| MAILTO | Cron emails anything a job prints. Set an address to receive it, or an empty string to stop the mail and the “No MTA installed” messages. | MAILTO="" |
| MAILFROM | Sender address on those emails, useful for filtering. | MAILFROM=cron@example.com |
| SHELL | Cron runs commands with /bin/sh. Set bash if a job uses bash-only syntax such as [[ ]] or arrays. This does not load .bashrc. | SHELL=/bin/bash |
| CRON_TZ | Time zone the schedule is evaluated in, instead of the system clock. Some crons call it TZ; check man 5 crontab. | CRON_TZ=Asia/Kolkata |
| RANDOM_DELAY | cronie and anacron only: delay every job by up to this many minutes to spread load. For one job, prefix it with sleep instead. | RANDOM_DELAY=3 |
Five places, and a job can hide in any of them. Jobs run as the user who owns the crontab, or the user named on the line in system crontabs, starting in that user's home directory.
| Place | Path | Runs as | Notes |
|---|---|---|---|
| Your crontab | /var/spool/cron/crontabs/<user> (or /var/spool/cron/<user>) | You | crontab -e to edit, crontab -l to list. Never edit the file directly: the editor validates it and tells cron to reload. |
| root's crontab | Same directory, file named root | root | sudo crontab -e. This is root's personal crontab, not the system one, so there is no user column. |
| System crontab | /etc/crontab | User named on each line | Sixth column is the user. Also holds the run-parts lines that drive the /etc/cron.* directories. |
| Drop-in files | /etc/cron.d/<name> | User named on each line | One file per app: cleanest for installers and config management. Must be owned by root or it is ignored. |
| Period directories | /etc/cron.hourly, .daily, .weekly, .monthly | root | Drop an executable script in; run-parts runs it. No schedule to write, but no control over the exact time either. |
Cron runs a command, so calling a URL means running a client such as curl or wget. Bound every call with a timeout, fail on HTTP errors so the exit code means something, and log the status.
The usual way to hit a web endpoint. -f makes curl exit non-zero on a 4xx or 5xx, -sS hides the progress bar but keeps errors, --max-time stops a hung request from piling up, --retry covers a blip.
*/5 * * * * curl -fsS --max-time 30 --retry 3 --retry-delay 10 -o /dev/null https://example.com/cron/run >> /var/log/cron-url.log 2>&1
Endpoints that do work should take POST, not GET, so a crawler or a stray click cannot trigger them. Send JSON or form fields.
0 * * * * curl -fsS --max-time 60 -X POST -H "Content-Type: application/json" -d '{"job":"hourly"}' https://example.com/api/jobs/run 0 * * * * curl -fsS -X POST --data-urlencode "job=hourly" https://example.com/cron.php
Print the HTTP status and the time taken on one line so the log shows what happened without keeping response bodies. Every % in a crontab must be escaped.
*/10 * * * * curl -sS -o /dev/null -w "\%{http_code} \%{time_total}s\n" --max-time 30 https://example.com/cron/run >> /var/log/cron-url.log 2>&1
The same call when only wget is installed. -q keeps it quiet, -O /dev/null discards the page, --tries and --timeout bound the attempt.
*/5 * * * * wget -q -O /dev/null --timeout=30 --tries=3 https://example.com/cron/run
Send the credential as a header or through a file, never in the query string. The Secrets tab shows how to keep the token out of the crontab and the process list.
0 3 * * * curl -fsS -H @/etc/app/cron-headers --max-time 60 https://api.example.com/v1/reports/nightly 0 3 * * * curl -fsS -n --max-time 60 https://api.example.com/v1/reports/nightly # -n reads ~/.netrc
When the job belongs to your own app, calling its CLI beats calling its URL: no web server timeout, no public endpoint to protect, real exit codes, and it runs even when the site is down.
* * * * * cd /srv/app && php artisan schedule:run >> /dev/null 2>&1 0 2 * * * cd /srv/app && /srv/app/.venv/bin/python manage.py send_digests 0 2 * * * cd /srv/app && /usr/bin/node scripts/nightly.js 0 2 * * * docker exec app-container /src/scripts/nightly.sh 0 2 * * * ssh -i ~/.ssh/cron_key deploy@host2 /srv/app/bin/nightly
If the URL must exist, treat it as an API: POST only, a secret header checked on the server, an allow list of caller addresses where possible, a fast reply with the work done in the background, and safe to call twice.
# server side, in pseudocode if request.method != "POST": return 405 if request.headers["X-Cron-Key"] != env("CRON_KEY"): return 403 if lock_held("nightly"): return 409 queue("nightly"); return 202
An API key typed into a crontab line is readable in more places than you would guess. Keep it in a file the job user alone can read, and hand it to the client in a way that keeps it off the command line.
| Where it shows | Why |
|---|---|
| crontab -l | Anyone with your login, and root, reads the whole line, including a key typed into it. |
| ps and /proc | Every user on the host can see the full command line of a running process, so a token in a curl argument is public for as long as the request runs. |
| Cron log | Cron writes the exact command line to syslog on every run. |
| Query string | A key in the URL lands in the server's access log, in proxies, and in any error page or redirect. |
| Cron mail | Output and errors are emailed. A verbose curl or a stack trace can print the header that carried the key. |
| Version control | A crontab or script committed with a key in it is there forever, in every clone. |
One line per variable, no export. Owned by the user the job runs as, mode 600, outside the web root and outside the repository.
sudo install -m 600 -o deploy -g deploy /dev/null /etc/app/cron.env # /etc/app/cron.env API_TOKEN=xxxxxxxxxxxxxxxx
Sourcing the file puts the value in the environment, which other users cannot read, but a header argument would still show in ps. Let curl read the header from a file instead, or use a netrc for user and password APIs.
# /etc/app/cron-headers (mode 600) Authorization: Bearer xxxxxxxxxxxxxxxx 0 3 * * * curl -fsS -H @/etc/app/cron-headers https://api.example.com/v1/run # ~/.netrc (mode 600) machine api.example.com login cronbot password xxxxxxxxxxxxxxxx 0 3 * * * curl -fsS -n https://api.example.com/v1/run
The crontab line then holds nothing sensitive. The script reads the env file, hands the header to curl on stdin, and keeps its own permissions tight. Never echo the variable and never run curl with -v.
# /srv/app/bin/nightly.sh (mode 700, owned by deploy) #!/bin/sh set -eu . /etc/app/cron.env printf 'Authorization: Bearer %s\n' "$API_TOKEN" | curl -fsS --max-time 60 -H @- https://api.example.com/v1/run # crontab 0 3 * * * /srv/app/bin/nightly.sh >> /var/log/nightly.log 2>&1
On cloud hosts, give the machine a role and read the secret with the provider's CLI when the job starts, so nothing sits on disk. On a desktop, the OS keychain works the same way.
TOKEN=$(aws secretsmanager get-secret-value --secret-id app/cron --query SecretString --output text) TOKEN=$(gcloud secrets versions access latest --secret=app-cron) TOKEN=$(security find-generic-password -s app-cron -w) # macOS keychain
| Rule | Detail |
|---|---|
| Least privilege | Create a token just for the job with only the scopes it needs, and run the job as its own user, not root. |
| Rotate | Change the key on a schedule and when someone leaves. A file-based key is one edit; a key baked into ten crontabs is a hunt. |
| Silence the mail | Set MAILTO="" or make sure the job never prints the header. Cron mail is stored in plain text. |
| Ignore it in git | Add the env file to .gitignore and commit an example file with placeholder values instead. |
| Permissions | Env file 600, script 700, log files 640, all owned by the job user. Check with ls -l after every deploy. |
| Audit | grep -r for the token prefix across /etc, home directories and the repository once, then again after the change. |
Write /usr/bin/curl, not curl, or set PATH at the top of the crontab. Half of all “works in the shell, fails in cron” reports are this.
Keep the crontab line to a schedule and a script path. Logic, pipes and quoting go in the script, where you can test it, version it and escape nothing.
Above each job: what it does, who owns it, where it is documented. Six months later that is the only thing that stops someone deleting it.
Append stdout and stderr to a file per job with >> file 2>&1, and let logrotate manage it. Cron itself only records that a job started.
Prefix with flock -n so runs cannot overlap, and write the job so running it twice is harmless. Cron will run it twice one day.
Wrap long jobs in timeout, for example timeout 15m /srv/app/bin/sync, so a stuck job is killed before the next run.
Scripts start with set -euo pipefail and exit non-zero on any failure. A job that swallows errors is one you hear about from a customer.
Do not put everything at 0 0. Odd minutes such as 7 3 spread load across your own jobs and away from everyone else's midnight.
Keep servers on UTC, or set CRON_TZ per crontab. On a local-time host a job at 02:30 can be skipped or run twice on the nights the clocks change.
Before scheduling: sudo -u user /bin/sh -c "cd ~ && command". After scheduling: run it every minute once, watch the log, then set the real schedule.
Run as a dedicated user, not root. Give it only the files, network and tokens the job needs.
Ship a file to /etc/cron.d from your installer or configuration management and keep it in version control. A server edit is invisible to the next deploy.
A log shows failures; nothing shows silence. Have each job touch a timestamp file or call an internal health URL when it finishes, and alert when that stops.
A cron job should decide and dispatch. Hand heavy work to a queue or worker, and skip sub-minute hacks; use a systemd timer or a daemon for those.
Set MAILTO to a monitored address, or to "" if you log to files. Unread cron mail fills disks and hides real errors.
The daemon logs when it starts, when it launches each job and when it cannot read a crontab. It never logs a job's output or exit code, and it cannot tell you about a job that did not run. You will usually need sudo to read these.
| System | File | Recent entries |
|---|---|---|
| Debian, Ubuntu | /var/log/syslog | grep CRON /var/log/syslog | tail -20 |
| RHEL, CentOS, Fedora | /var/log/cron | tail -20 /var/log/cron |
| systemd journal | journalctl | journalctl -u cron (or crond) |
Mar 29 16:15:01 data-processing CRON[12624]: (dataproc) CMD (/home/data-pipeline.py) │ │ │ │ └ the command │ │ │ └ user the job ran as │ │ └ process id │ └ host └ when the job was started
| Message or symptom | Cause | Fix |
|---|---|---|
| bad minute | A line that is not blank, a comment or a variable does not start with a valid minute. Usually a long line wrapped onto two, a comment missing its #, or hours and minutes swapped. | The message names the line number. Put schedule and command on one line, start comments with #, check the first field is 0-59. |
| missing newline before EOF | The last line has no trailing newline. Editors add it; scripts that generate crontabs often forget. | Add a blank line at the end. Fix the generator so it always writes a final newline. |
| errors in crontab file, can't install | Generic wrapper for any syntax error when saving. | Read the specific message above it, usually one of the two above. man 5 crontab has the full grammar. |
| (CRON) info (No MTA installed, discarding output) | The job printed something and there is no mail agent to email it. The job itself ran fine. | Set MAILTO="" in the crontab, redirect output to a log file, or install postfix and read /var/mail/<user>. |
| WRONG FILE OWNER | A file in /etc/cron.d or /etc/cron.* is not owned by root, so cron skips it. | sudo chown root:root the file. |
| Works in the terminal, fails under cron | Cron does not read .bashrc or .profile, runs /bin/sh not bash, starts in the user's home directory and has an almost empty PATH. | Use absolute paths, set PATH and other variables in the crontab, cd first if the script uses relative paths, or set SHELL=/bin/bash. |
| Command cut off at a % sign | In a crontab, an unescaped % ends the command and everything after it becomes stdin. | Write \% instead, for example date +\%F. |
| Nothing in the log at all | The daemon is not running, the crontab was never reloaded, or the user is blocked by /etc/cron.allow or /etc/cron.deny. | pgrep cron to check the daemon. EDITOR=true crontab -e forces a reparse and reports “No modification made” when all is well. |
| The crontab is empty | crontab -r removes the whole crontab with no confirmation, and it is one key away from crontab -e. Config management such as Ansible can also overwrite it. | Restore from a backup or the config source. Keep crontabs in version control or in /etc/cron.d files. |
Cron logs only that a job started, never what it printed or its exit code. Redirect stdout and stderr yourself. Two arrows append, one arrow overwrites on every run.
*/5 * * * * /home/crons/send-updates.py >> /home/crons/send-updates.log 2>&1
Cron starts the next run on schedule even if the last one is still going, and a slow day can pile up dozens of copies. flock takes a lock file first and, with -n, skips the run when the lock is held.
*/5 * * * * flock -n /tmp/send-updates.lock /home/crons/send-updates.py
Declare them on their own lines above the jobs, without export. For a value that differs per job, put it inline before the command. For many variables, source a file first.
PATH=/usr/local/bin:/usr/bin:/bin MAILTO="" 0 * * * * APP_ENV=production /srv/app/export.py 0 0 * * * APP_ENV=staging /srv/app/export.py 0 3 * * * . /etc/app.env; /srv/app/nightly.sh
Jobs start in the owner's home directory. If a script relies on relative paths, change into its directory first, or put its directory on PATH.
0 * * * * cd /srv/app && ./job.sh
Use a system crontab, which has a user column. A file in /etc/cron.d keeps each app's jobs together. Note that sudo crontab -e edits root's own crontab, which has no user column.
# /etc/cron.d/database-backup 0 0 * * * dataproc /srv/bin/database-backup.sh
Cron cannot go below one minute. Schedule a wrapper every minute that runs the job twice with a 30 second sleep, and lock it so copies cannot stack up. A systemd timer with OnCalendar=*-*-* *:*:00,30 does this natively.
#!/bin/bash for i in 1 2; do /home/crons/send-updates.py & sleep 30 done # crontab: * * * * * flock -n /tmp/wrapper.lock /home/crons/wrapper.sh
Reproduce a failure by running as the right user, with /bin/sh, from the home directory and with a clean environment. Paste the command exactly as it appears after the schedule.
sudo -u <user> /bin/sh -c "cd ~ && <command from the crontab>" # or a fully empty environment: env -i /bin/sh
grep the process list for the command. More than one line means the job is hanging, is scheduled twice, or takes longer than its interval. The second command lists every process cron started.
ps aux | grep "/home/crons/send-updates.py" | grep -wv grep ps h --ppid $(pgrep cron)
Either keep the schedule on the host and run the job inside the app image, or build a small cron container that installs cron and copies a crontab into /etc/cron.d. Base the second image on the app image so it shares dependencies and secrets.
# host crontab 0 8 * * * docker run --rm acme:app /src/scripts/send-coupon-mail.sh # Dockerfile for a cron container RUN apt-get update && apt-get install -y cron COPY Crontab /etc/cron.d/app CMD cron && tail -f /var/log/cron.log
When nothing else helps, schedule the simplest possible job every minute and tail the file. Once that ticks, swap in your command and see what changes.
* * * * * date >> /tmp/cronlog
crontab -l for yours, crontab -u <name> -l for other users, then /etc/crontab, /etc/cron.d and the /etc/cron.* directories. Make sure you are on the right server.
Paste it into the box above and read the next run times. Compare with date on the server and look for TZ or CRON_TZ lines in the crontab.
The script must be executable by the user cron runs it as (chmod +x). Files in /etc/cron.d must be owned by root. The user must not be in /etc/cron.deny, and must be in /etc/cron.allow if that file exists.
grep the cron log for the command. No entry means cron never tried: check pgrep cron, force a reparse with EDITOR=true crontab -e, or temporarily set the schedule to every minute. Remember log rotation: the previous file ends in .1.
Same user, /bin/sh, home directory, empty environment. Check runtime versions too: a Python virtualenv not activated, an old system Node, or a different php.ini are common culprits.
ps for duplicate copies and add flock or run less often. Then the boring causes: a full disk, no memory, grown data that now times out, rotated credentials, or a retired host that still owned the job.
For jobs that run on time
The nightly backup. Five stars and numbers become every night at two.
BeforeRead a line of stars and hope it is right
With sdevSee the next run times in plain English
A calm morning
The report ran on time. Coffee tastes better.
Team planning
Everyone reads the schedule in plain words.
Enter five space-separated fields, a macro such as @daily, or pick one of the presets. Each field is labelled under the box as you type so you can see which part is which.
The plain-English sentence updates on every keystroke. If a field is wrong, the error names the field and the value that is out of range.
Pick the server's time zone and the next ten runs are listed in that time and in yours, with a note on any run the clock change skips or repeats. The Fields table shows exactly which values each part expands to.
Type the expression and read what it means in plain English.
List the next ten run times in your time or in UTC.
Pick every hour, every day at midnight or weekdays, then change it.
Follow the guide on paths, logs and keys.
Turn a Unix timestamp from the job log into a date.
Unix timestamp converterIt explains and teaches at the same time, with fixes for the common reasons a cron job does not run.
sdev.in. (n.d.). Cron expression parser and editor [Web tool]. https://www.sdev.in/tools/cron-parser
"Cron expression parser and editor." sdev.in, https://www.sdev.in/tools/cron-parser.
sdev.in. "Cron expression parser and editor." https://www.sdev.in/tools/cron-parser.
@misc{sdev-cron-parser,
title = {Cron expression parser and editor},
author = {{sdev.in}},
howpublished = {\url{https://www.sdev.in/tools/cron-parser}},
note = {Web tool}
}In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12 or JAN-DEC) and day of week (0-7 or SUN-SAT, where both 0 and 7 mean Sunday). A star means every value.
Yes. A leading seconds field, as used by Quartz, Spring and some cloud schedulers, is dropped and the remaining five fields are read as normal. Seconds are not evaluated, so run times are shown to the minute.
The tool follows Vixie cron, the cron on Linux and macOS: when both fields are restricted a run happens if either one matches. So 0 0 1 * 1 fires on the 1st of every month and on every Monday.
Cron uses the clock of the machine it runs on, not yours. Pick that machine's zone under Server time zone; most cloud servers and containers use UTC. Each run is then shown in the server's time and in your own. The default is your own zone, for a job on your own computer.
On the night the clocks go forward, times such as 02:30 do not exist; on the night they go back, 01:30 happens twice. Linux cron runs a skipped job right after the jump and a repeated one only once, but other schedulers may skip or repeat it. The run list marks both cases. Keeping servers on UTC, or not scheduling between 01:00 and 03:00, avoids the problem.
Cron runs it with /bin/sh, from your home directory, without reading .bashrc or .profile and with an almost empty PATH. Use absolute paths, set PATH and any variables at the top of the crontab, and test with sudo -u user /bin/sh -c "cd ~ && command". The reference below has the full checklist.
Debian and Ubuntu write to /var/log/syslog, Red Hat family to /var/log/cron. Cron only logs that it started a job, never what the job printed. Append >> /path/job.log 2>&1 to the crontab line to keep the output yourself.
Put it in a file owned by the job user with mode 600 and let the client read it from there, for example curl -H @/etc/app/cron-headers or a ~/.netrc. A key typed on the crontab line shows up in crontab -l, in ps for every user on the host, and in the cron log. The Secrets tab in the reference walks through it.
Run curl or wget as the command: curl -fsS --max-time 30 https://example.com/cron/run. Use -f so HTTP errors give a non-zero exit code, a timeout so a hung request cannot pile up, and escape any % as \%. If the job belongs to your own app, its CLI command is usually the better choice.
The search stops after five years. An expression that can never match, such as day 31 in February, or day 30 in February, produces no runs at all.