Reading a cron expression
A crontab line has five time fields followed by the command: minute hour day-of-month month day-of-week. So 30 2 * * 1-5 means 02:30 on weekdays, and */15 * * * * means every fifteen minutes. The two classic traps: day-of-week runs 0–6 with 0 = Sunday (7 also works as Sunday in most crons), and when you set both day-of-month and day-of-week, standard cron runs the job if either matches (an OR, not an AND) which surprises almost everyone the first time.
Habits that prevent 3 a.m. surprises
Cron jobs run with a minimal environment: a near-empty PATH, no shell profile, and often a different default shell. The job that works when you paste it into your terminal and fails silently from cron is almost always an environment problem. Use absolute paths for every binary, set PATH explicitly at the top of the crontab, and capture output, >> /var/log/myjob.log 2>&1, so failures leave evidence. Setting MAILTO=you@example.com gets you emailed on any output, which for a well-behaved job means only on failure.
Timezones and DST
Cron uses the system timezone, and jobs scheduled between 01:00 and 03:00 can run twice or not at all when daylight saving shifts. If a job genuinely must run once per day regardless of DST, schedule it outside that window or run the host on UTC, which is good practice for servers anyway.
When to use systemd timers instead
On modern Linux, systemd timers offer things cron cannot: Persistent=true to catch up on runs missed while the machine was off, RandomizedDelaySec to stop a fleet stampeding a service at the same second, per-job resource limits, and logs in journalctl. Cron remains perfect for simple, always-on servers; for laptops, batch fleets, and jobs that must never be silently skipped, timers are worth the extra unit file.