A LITTLE LINUX, A LOT LESS GUESSWORK
Tell Ubuntu when to run your command. Build a cron schedule, understand what it means, and add it safely — one small step at a time.
THE SAFE NEXT STEP
The download is a snippet to review, not an installer. These instructions are for you to run deliberately on your Ubuntu machine. This website never changes your system.
List your current user's jobs without sudo:
crontab -lIf jobs exist, save them to a new, unused backup filename before editing:
crontab -l > "$HOME/crontab-backup-$(date +%Y%m%d-%H%M%S).txt"Check that the command succeeded and inspect the backup. Stop on permission or other errors. If cron explicitly says there is no crontab for you, you can start a new one.
The % in this terminal-only backup command is fine. Inside a crontab command, it would need escaping.
Open your current user's crontab:
crontab -eKeep existing jobs. Add your reviewed comment and job line. Reconcile SHELL/PATH settings carefully: environment lines affect all following jobs, not just this one. Save and exit to install the edited table.
Do not run crontab downloaded-file just to add one job. That replaces your entire current crontab. Never edit cron's spool files directly.
Run crontab -l again and confirm both old and new jobs are present. Cron must already be available and running on the host; this app doesn't install or start it.
For the hello example, look in your configured logging system, such as journalctl -t cron-learning. Wait for a selected minute; cron is not a second-precision scheduler.
To remove just this job, use crontab -e and remove only its line and any no-longer-needed settings. crontab -r removes the whole table.
Use this only when you understand system administration. Select system format in the builder and specify an existing, least-privileged account. Its format is minute hour dom month dow username command, or @macro username command. Do not paste this format into crontab -e; the username would become part of the command.
An administrator can create a new reviewed file such as /etc/cron.d/learning-job. Avoid overwriting existing files. Under Ubuntu cron's default naming rules, use only ASCII letters, digits, underscores and hyphens — no dot or .txt extension. The app's system download is named learning-job accordingly.
Use a regular file owned by root (conventionally root:root), mode 0644 (not group/other-writable); it does not need executable permission. End every line with a newline. It has its own environment and does not inherit /etc/crontab settings. Verify the account with id username. The app checks conservative username syntax, not account existence or permissions.
Never install a system-format file with crontab filename. Cron normally detects file changes; this guide does not require a service restart. Files in /etc/cron.daily are executable scripts, a different mechanism, not this format.
A FEW THINGS WORTH KNOWING
0 9 1 * 1 means 09:00 on the 1st or any Monday. If a day is both, it runs once at that matching minute, not twice. Minute, hour and month must still all match.
Ubuntu/Vixie cron checks whether either day field starts with *. If so, both day tests must match. 0 9 */2 * 1 means Mondays on odd-numbered dates, not all Mondays plus odd dates.
1-31 covers all dates but is not syntactically a wildcard. Order matters: *,1 starts with *; 1,* does not. We preserve your syntax, never normalize it into a different day rule. Sunday is 0 or 7. Dates such as February 31 do not exist.
/usr/bin/date '+%F' is not safe as-is in a crontab. Write /usr/bin/date '+\%F' for a literal percent passed to the shell. Shell single or double quotes do not hide % from cron.
An unescaped % ends the shell command and sends the rest as standard input, converting later percent signs to newlines. With multiple backslashes, an odd number immediately before % escapes it; an even number does not. This app warns and requires acknowledgment for intentional unescaped percent syntax. It never rewrites it.
Cron is not your interactive terminal: no shell aliases, activated virtual environments or normal login profile. Use absolute command and interpreter paths. Jobs normally start in the account's home directory. For another directory, explicitly use cd /absolute/project && /absolute/script.
Choose the right shell. Ensure the account can read required files, traverse directories, execute scripts, and write logs. A directly executed script needs an executable bit and an appropriate shebang. Never put passwords or tokens in a crontab or public example; use a suitably protected configuration file. Command validation is not a shell correctness or security audit.
Output may be mailed only if a mail transport is configured. Do not assume you will receive errors. For a file log, append >> "$HOME/job.log" 2>&1 to a reviewed command. > truncates; >> appends. Keep logs private when needed, ensure write permission, and plan rotation.
Cron starts a new invocation even if the old one is still running. For a single-instance script, consider /usr/bin/flock -n "$HOME/.learning-job.lock" /absolute/script. Check that flock exists and the lock is in a private, writable directory. -n skips a busy invocation rather than queues it; handle/report failures in your script. A lock is not retry or recovery logic.
Baseline: Ubuntu 22.04 LTS (Jammy), Debian/Vixie-derived cron 3.0pl1-137ubuntu3 family. Check your host with dpkg-query -W cron and read its installed man 5 crontab / man 8 cron. Other Ubuntu releases or installed packages (such as Cronie) can differ.
Schedules use the daemon's configured system timezone. Check the host using timedatectl; the browser's timezone is not authoritative. In this baseline, TZ changes the command's environment, not its schedule. Do not assume CRON_TZ support.
Ubuntu cron treats clock changes under three hours specially: fixed-time jobs missed by a forward change run soon afterward; repeated fixed times after a backward change are not re-run. Wildcard minute/hour schedules follow the new time immediately. These syntactic distinctions matter — do not assume every cron package simply skips or duplicates every DST job. Larger corrections use the new time immediately. We deliberately provide no next-run/DST simulator.
Ordinary jobs missed while the host is off or cron is stopped are not automatically replayed. Anacron can catch up configured daily/weekly/monthly tasks, not arbitrary minute jobs. systemd timers offer dependency integration and optional persistent calendar timers; configure those intentionally for your needs.
@reboot is a cron startup hook handled by Ubuntu's daemon, not a fixed timestamp or an ordering contract. It may run before the network or another service is ready. It does not make your command a managed service, keep it alive, or retry a failure. Use a systemd service with explicit dependencies when readiness and lifecycle matter.
Other supported macros are calendar shortcuts: @hourly, @daily/@midnight, @weekly, @monthly, @yearly/@annually. They are not intervals measured from installation.