Free Cron Job Expressions Cheat Sheet Online — Crontab Syntax, Patterns & Scheduling Reference

Cron is the silent workhorse of the internet. Every database backup that runs at 2 AM, every log rotation at midnight, every certificate renewal check, every cache clear — behind them all is a cron expression, five numbers and stars that tell a machine when to act. Our free interactive Cron Job Expressions Cheat Sheet gives you instant access to 120 cron expressions, crontab management commands, and scheduling patterns across 10 categories, with real-time search, one-click copy, and a Clockmaker's Workshop aesthetic. No signup. No server. 100% client-side.

Why Cron Still Matters in 2026

In an era of serverless functions, event-driven architectures, and Kubernetes CronJobs, the original Unix cron daemon — first released in Version 7 Unix in 1979 — remains the most widely deployed task scheduler on the planet. Every Linux server ships with cron. Every macOS machine has it. CI/CD platforms (GitHub Actions, GitLab CI, Jenkins) use cron syntax for scheduled pipelines. Cloud providers (AWS EventBridge, GCP Cloud Scheduler) accept cron expressions. Kubernetes CronJobs use the same five-field syntax.

The syntax has not changed in 45 years. But it is cryptic. Five space-separated fields, each with its own range and special characters. Get one asterisk wrong and your job fires every minute instead of every day. Misunderstand the interaction between day-of-month and day-of-week and your job runs when you least expect it. The cheat sheet eliminates this guesswork — find the pattern you need, copy it, done.

Cron Syntax Fundamentals — The Five Fields

A cron expression is five space-separated fields followed by a command: minute hour day-of-month month day-of-week command. Minute is 0-59, hour is 0-23 (24-hour format), day-of-month is 1-31, month is 1-12 (or JAN-DEC), and day-of-week is 0-7 (both 0 and 7 are Sunday) or SUN-SAT. Every field accepts numbers, ranges, lists, steps, and the asterisk wildcard.

The cheat sheet's Syntax Fundamentals category breaks down each field with its allowed values and special character support. * * * * * command means every minute of every day — 1,440 executions in 24 hours. 0 0 * * * command means midnight daily. 0 9 * * 1-5 command means 9:00 AM on weekdays. 0 0 1 1 * command means once per year at midnight on January 1. We also cover the predefined macros — @yearly, @monthly, @weekly, @daily, @hourly, and @reboot — that replace the full five-field expression with a single readable word.

Everyday Scheduling Patterns — The 80/20 of Cron

Most people need the same dozen cron expressions over and over. Every 5 minutes for health checks, every 15 minutes for cache refresh, every hour for log analysis, daily at midnight for backups, weekly on Sunday for maintenance, monthly on the 1st for reporting. Our Everyday Scheduling Patterns category covers this 80/20: */5 * * * * for polling, */15 * * * * for frequent batches, 0 * * * * for hourly jobs, 0 */6 * * * for 4-times-daily, 0 0 * * * for midnight daily, 0 2 * * 0 for weekly maintenance windows, and 0 0 1,15 * * for bi-monthly processing on the 1st and 15th.

These patterns are battle-tested. Copy them directly from the cheat sheet, substitute your command, and your scheduling is correct by construction. No more counting asterisks or wondering whether Sunday is 0 or 7.

Special Characters — The Power Tools

The real expressiveness of cron comes from its special characters. The asterisk (*) matches every value — "every minute" or "every hour" depending on the field. The comma (,) creates value lists: 1,3,5 in the hour field means "at 1 AM, 3 AM, and 5 AM." The hyphen (-) defines ranges: 9-17 means every hour from 9 AM through 5 PM. The slash (/) defines step values: */15 means every 15 units.

But there is more. Extended cron implementations (Quartz, Jenkins) add powerful characters that POSIX cron lacks. L means "last" — 0 0 L * * runs on the last day of any month, and 0 0 * * 1L runs on the last Monday. W finds the nearest weekday to a given day. # selects the nth weekday: 0 0 * * 1#2 is the second Monday of the month. Jenkins uses H for hashed load distribution so every project's hourly job doesn't all fire at minute 0. Every special character is documented in the cheat sheet with practical examples and behavior descriptions.

Cron Job Management — Installing, Listing, and Removing

Writing cron expressions is half the battle. Managing them is the other half. Our Cron Job Management category covers the complete crontab CLI: crontab -e to edit your jobs, crontab -l to list them, crontab -r to remove them (use -i for interactive confirmation — accidental -r instead of -e is a rite of passage), crontab -u username -e to edit another user's crontab as root, and sudo crontab -e for system-wide root jobs.

We also cover the system-level cron directories: /etc/crontab (the system-wide crontab with an extra user field between the schedule and command), /etc/cron.d/ (package-installed cron jobs), and /etc/cron.{hourly,daily,weekly,monthly}/ (directories where you drop executable scripts that run via run-parts). Knowing the difference between user crontabs and system cron directories prevents confusion when debugging why a job is or isn't running.

Advanced Intervals — Beyond the Basics

Some scheduling needs go beyond simple patterns. How do you run a job on the first Monday of every month? Combine day-of-month and day-of-week constraints: 0 0 1-7 * 1 — "midnight on any of the first 7 days AND it's Monday." This narrows to exactly the first Monday. For the third Tuesday, use 0 0 15-21 * 2. For every 2 hours during business hours on weekdays: 0 9-17/2 * * 1-5.

The Advanced Intervals category covers these compound patterns, leap-year edge cases (a job scheduled for February 29 only fires in leap years — the cheat sheet shows how to handle this), weekend-only schedules (0 12 * * 6,7 for noon on Saturday and Sunday), and multi-time schedules using comma-separated lists in the hour field. Every pattern includes both the expression and an English description of when it fires.

Environment & Output — What Cron Doesn't Tell You

The most common reason a cron job "doesn't work" is the environment. Cron runs with a minimal environment — a stripped-down PATH, no user profile sourced, no shell aliases, no DISPLAY variable. Your script works perfectly in your terminal and silently fails in cron. Our Environment & Output category is the antidote: SHELL=/bin/bash to override the default /bin/sh, PATH=/usr/local/bin:/usr/bin:/bin to ensure your commands are found, MAILTO=admin@example.com to receive error output, and . $HOME/.profile to source your full environment before the command runs.

We cover output redirection exhaustively: > /dev/null 2>&1 to suppress all output, >> /var/log/task.log 2>&1 to log both stdout and stderr, 2>&1 | logger -t cron-task to route output to syslog, and || echo "failed" >> errors.log to log only failures. Preventing overlapping runs with flock and enforcing timeouts with timeout are also covered — these are the patterns that separate hobbyist cron usage from production reliability.

Real-World Examples — Copy-Paste Solutions

Sometimes you don't want a reference; you want a recipe. Our Real-World Examples category provides complete, copyable cron entries for the most common operational tasks. A PostgreSQL database backup with dated filename: 0 2 * * * pg_dump dbname > /backups/db_$(date +\%)Y\%m\%d).sql. Weekly log cleanup for files older than 30 days: 0 3 * * 0 find /var/log -name "*.log" -mtime +30 -delete. Monthly SSL certificate renewal with nginx reload: 0 0 1 * * certbot renew --quiet --post-hook "nginx -s reload".

We also include a health-check watchdog (systemctl is-active --quiet nginx || systemctl restart nginx), disk space monitoring with email alerts, offsite rsync backups, daily API data ingestion, and temp file cleanup. Each example is a complete, production-tested cron entry — replace the paths and commands with your own, and you have a working scheduled job in seconds.

Validation & Debugging — When Cron Goes Silent

Cron's greatest weakness is its silence. When a job fails, cron typically emails the output to the local user — but on modern systems without a configured MTA, those emails disappear into the void. Our Validation & Debugging category gives you the tools to see what cron is actually doing: grep CRON /var/log/syslog to view execution logs, journalctl -u cron -f to follow cron in real time on systemd systems, run-parts --test /etc/cron.daily to verify which scripts would execute, and the critical env -i HOME=$HOME PATH=/usr/bin:/bin /bin/sh -c "/your/script.sh" trick that simulates cron's minimal environment so you can test your script under the exact conditions cron will run it.

We also cover syntax validation: piping your crontab to itself (crontab -l | crontab -) triggers a parse that rejects invalid syntax, and online validators like crontab.guru provide instant human-readable explanations of any cron expression. For deeper debugging, running the cron daemon with CRON_LOGLEVEL=15 shows every scheduling decision, parsing step, and execution detail.

Cron in DevOps — Beyond the Traditional Crontab

Cron syntax has escaped the Unix crontab and colonized the DevOps landscape. GitHub Actions uses it for scheduled workflows (on: schedule: - cron: "0 0 * * *"). GitLab CI has pipeline schedules with standard cron. Jenkins cron triggers use H (hash) for load distribution. Kubernetes CronJobs run containers on cron schedules. AWS EventBridge Scheduler accepts 6-field cron expressions for serverless invocations. Vercel and Cloudflare Workers both offer cron-triggered function execution.

Our Cron in DevOps category documents the cron syntax and nuances of each platform. GitHub Actions cron uses 5-field POSIX syntax but has a minimum interval of 5 minutes and fires on a best-effort basis during high load. Kubernetes CronJobs support concurrencyPolicy to control overlapping runs. systemd timers offer OnCalendar= with a more expressive syntax than cron. AWS EventBridge requires a 6-field expression (it adds a year field). Quartz Scheduler uses 7 fields (adding seconds and optional year). Understanding these platform-specific wrinkles prevents production incidents.

Troubleshooting — The Top 12 Cron Failure Modes

After decades of cron usage across millions of systems, the same failure modes appear again and again. The PATH is too minimal and commands aren't found. Percent signs in command arguments get interpreted as newlines (escape them as \%). The environment lacks variables that your interactive shell has (source your profile explicitly). The script runs when tested manually but fails in cron because cron's environment is barren. Overlapping runs cause resource contention. The timezone isn't what you think it is. The crontab doesn't end with a newline, so the last job is silently ignored.

Our Troubleshooting category catalogs all twelve failure modes with diagnostic steps and fixes. The most notorious — accidentally typing crontab -r (remove) instead of crontab -e (edit) — is the first entry, with preventive advice: always alias crontab to crontab -i or keep a backup. The day-of-month AND day-of-week interaction (when both are specific values, cron runs on either match, not both) is another common surprise documented with examples.

The Clockmaker's Workshop — Aesthetic Design

Cron is about precision timing — the kind of precision that master clockmakers have practiced for centuries. Our Cron Job Expressions Cheat Sheet embraces The Clockmaker's Workshop aesthetic: a deep mahogany workshop background with a warm lantern glow radiating from the top-center, like a craftsman's workbench lit by an incandescent bulb. Six large brass gears rotate slowly in the background (pure CSS animation at 0.04 opacity) — an homage to the mechanical clockwork that cron abstracts into five fields. The Cinzel display font, with its classical engraved inscriptions, evokes the numerals on an antique clock face. Crimson Text provides warm, readable body copy as rich as aged paper. JetBrains Mono serves code and cron expressions with the precision of a watchmaker's loupe.

A brass pendulum indicator swings along the top edge, marking the passage of time. Floating brass dust particles drift upward like metal filings in a sunbeam. Category cards are styled as engraved brass plates with a diamond-marker corner decoration that glows on hover. The color palette is drawn entirely from a clockmaker's materials: polished brass #c9a050, gold pendulum #daa520, copper springs #d07840, bronze bearings #a08040, steel escapements, silver dials, rose gold, and nickel — each assigned to a category and rendered as a gear-dot section header and card left border. This is not a generic dark-mode interface; it is a deliberate, crafted space that makes scheduling feel like precision work.

How This Cheat Sheet Fits Into Your Workflow

The Cron Job Expressions Cheat Sheet is part of the DevToolkit suite of free developer reference tools. It complements our Linux Commands Cheat Sheet (which covers the crontab CLI and systemctl for service management), our DevOps Commands Cheat Sheet (covering Docker, CI/CD, and infrastructure automation), and our Bash Scripting Cheat Sheet (the commands that cron executes). Together they form a terminal-and-automation reference cluster for developers and sysadmins who work at the command line.

The workflow is simple: press Ctrl+K to focus the search bar, type what you need (a keyword, a cron special character, a platform name), and the matching entries appear instantly. Click any card to copy its cron expression to your clipboard. Filter by category to narrow the view. Everything runs in your browser — no server requests, no signup, no tracking. Bookmark it, use it in your terminal sessions, and stop guessing at cron syntax.