What is a cron job and how do you read one
Tools Nimbus is a free, no-signup developer toolkit that runs entirely in your browser, so your data is never uploaded to a server. A cron job is a task a scheduler runs automatically on a repeating clock schedule, described by a five-field cron expression such as 0 9 * * 1-5. Paste any expression into the free Cron Expression Explainer to read it in plain English and see its next run times.
Last updated July 2026
The short answer
A cron job has two halves: a schedule and a command. The schedule is written as a cron expression, and the command is whatever you want run on that schedule. On Linux and macOS a background service named cron wakes up once a minute, compares the current time against every schedule it knows about, and runs the commands that match. Those schedules live in a file called a crontab (cron table), edited with crontab -e. The word "cron job" simply means one line of that table: one schedule paired with one command.
The reason the syntax is worth learning is that it outlived the daemon it was written for. Kubernetes CronJobs, GitHub Actions schedules, GitLab CI, AWS EventBridge, Spring, and most managed job runners all accept cron expressions. Learn the five fields once and you can schedule work almost anywhere.
How to read the five fields
A standard cron expression is five values separated by spaces, always in the same order. Read left to right, they get progressively coarser: minute, hour, day of month, month, day of week.
| Position | Field | Allowed values | Example |
|---|---|---|---|
| 1 | Minute | 0-59 | 30 means minute 30 |
| 2 | Hour | 0-23 (24-hour clock) | 14 means 2 PM |
| 3 | Day of month | 1-31 | 1 means the 1st |
| 4 | Month | 1-12 | 6 means June |
| 5 | Day of week | 0-6, where 0 is Sunday | 1-5 means Monday to Friday |
Four symbols do all the work. An asterisk (*) means every value for that field. A hyphen makes a range (1-5). A comma makes a list (1,15,30). A slash makes a step, applied to the range in front of it, so */15 means every fifteenth value and 1-5/2 means every second value from 1 to 5. Put those together and 0 9 * * 1-5 reads as: at minute 0 of hour 9, every day of month, every month, on Monday through Friday.
Expressions you will actually write
| Expression | When it runs |
|---|---|
* * * * * | Every minute |
*/5 * * * * | Every 5 minutes |
0 * * * * | Every hour, on the hour |
30 2 * * * | Every day at 2:30 AM |
0 9 * * 1-5 | 9:00 AM on weekdays |
0 0 * * 0 | Midnight on Sundays |
0 0 1 * * | Midnight on the 1st of every month |
0 0 1 1 * | Midnight on 1 January |
The day-of-month and day-of-week trap
This is the single most misread part of cron, and it catches experienced engineers. Fields normally combine with AND: every field must match for the job to run. The two day fields are the exception. As the crontab(5) manual puts it, if both the day-of-month and day-of-week fields are restricted (neither one is an asterisk), the command runs when either matches, not both. So 0 0 1 * 1does not mean "the first of the month, if it is a Monday". It means "every 1st of the month, and also every Monday", which is roughly five times more often than intended. If only one of the two day fields is restricted, the usual AND behavior applies. When you need "the first Monday of the month", the standard workaround is to schedule 0 0 1-7 * *, leaving the day-of-week field unrestricted, and then have the command itself exit early unless today is a Monday. Cron alone cannot express the AND of two day fields.
Time zones: why your job ran at the wrong hour
A cron expression carries no time zone. It is interpreted in whatever zone the scheduler is configured for, and modern schedulers overwhelmingly default to UTC. Kubernetes CronJobs evaluate schedules in UTC unless you set spec.timeZone(supported since Kubernetes 1.27), AWS EventBridge rules are evaluated in UTC, and most hosted CI schedulers do the same. A classic Linux crontab, by contrast, uses the machine's local zone, which is why the same expression can behave differently on a laptop and in a cluster.
Two consequences follow. First, translate your intended local time into UTC before writing the expression, and write down which zone you meant in a comment. Second, daylight saving time will shift a UTC-based job by an hour relative to local time twice a year, so schedule anything time-sensitive in a window where an hour of drift does not matter. If you are reconciling log timestamps against schedules, the Unix Timestamp Converter turns epoch values into readable UTC and local times, and our guide on why a Unix timestamp shows 1970 covers the related unit mistakes.
Which cron flavor are you writing for
The five-field format is the common core, but several widely used systems extend it. Copying an expression between them without checking the field count is a reliable way to schedule something for the wrong time or to get a parse error.
| Capability | Unix cron / Kubernetes | Quartz and Spring | AWS EventBridge |
|---|---|---|---|
| Field count | 5 | 6 or 7 | 6 |
| Seconds field | No | Yes (first field) | No |
| Year field | No | Optional (last field) | Yes (last field) |
| Day of week | 0-6, Sunday is 0 | 1-7, Sunday is 1 | 1-7, Sunday is 1 |
| Default time zone | Local for classic cron, UTC for Kubernetes | Scheduler configuration | UTC |
| Shorthand macros | @daily, @hourly, @reboot | No | rate() expressions instead |
The day-of-week numbering row is the quiet one. Standard cron treats 0 as Sunday and 6 as Saturday (many implementations also accept 7 for Sunday), while Quartz and EventBridge count 1 as Sunday. Move 0 9 * * 1-5 from a crontab into EventBridge unchanged and you have shifted your weekday job onto Sunday through Thursday.
Shorthand macros
Classic cron accepts a handful of named shortcuts in place of all five fields: @yearly (identical to @annually), @monthly, @weekly, @daily (identical to @midnight), @hourly, and @reboot. The first five are plain aliases, so @daily is exactly 0 0 * * *. @reboot is the odd one out: it is not a clock schedule at all, it runs the command once when cron starts up. Portable code should prefer the explicit five-field form, because macro support varies between cron implementations and most non-Unix schedulers reject them outright.
When a cron job is the wrong tool
Cron is for work that should happen on a clock, independent of what users do: nightly backups, hourly report generation, weekly cleanup of expired rows, a daily digest email. It is a poor fit for three cases. Work that should happen in response to an event (a file lands, a payment settles) belongs in a queue or a webhook, not on a five-minute poll. Work that needs second-level precision is outside standard cron's one-minute resolution, so use a Quartz-style scheduler or a long-running worker. And work that must run exactly once even if the machine was asleep needs a scheduler with catch-up semantics, since classic cron simply skips a run whose moment has passed. Also remember that cron does not prevent overlap: if a job takes longer than its interval, the next run starts anyway unless you add a lock.
Check the expression before you ship it
The cheapest way to avoid a job that fires 1,440 times a day instead of once is to read the schedule back in plain English before deploying it. Several free tools do this, and they are genuinely close in quality.
| Capability | Tools Nimbus Cron Expression Explainer | crontab.guru |
|---|---|---|
| Price as of 2026 | Free | Free |
| Account required | No | No |
| Plain-English description | Yes | Yes |
| Next run times | Yes, in your browser's local zone | Yes |
| Shareable URL for an expression | No | Yes |
| Syntax accepted | 5-field numeric, with ranges, lists, and steps | 5-field, plus macros and name abbreviations |
| Parsing location | Entirely in your browser | Not documented |
Be honest about the trade-off: if you want a single-purpose editor with a shareable link you can paste into a pull request, crontab.guru is the better pick and has been the reference for years. Our Cron Expression Explainer is worth using when you would rather not send an internal schedule string anywhere, since it parses locally and never uploads what you type, and when you want the neighbouring tools on the same site. It accepts numeric five-field expressions with ranges, lists, and step values; it does not accept @daily style macros or three-letter names like MON, so expand those to numbers first. It also implements the day-of-month and day-of-week OR rule described above, which is exactly the case worth double-checking.
For comparing two versions of a crontab before you replace one, the Diff Checker highlights changed lines locally. More walkthroughs like this one live on the Tools Nimbus guides index, including our guide to a free alternative to epochconverter.com for the time conversions that usually come up alongside scheduling work.