Cron expression reader

Paste a crontab line to find out what it actually means, see each field explained against its allowed range, and get the next five times it will fire.

Five fields: minute hour day-of-month month day-of-week

Common schedules
Your file is processed by your own browser. Nothing is uploaded, stored or logged.

A cron expression is five fields — minute, hour, day of month, month, day of week — and the syntax is compact enough to be easy to misread. The difference between */15 * * * * and 15 * * * * is ninety-six runs a day versus twenty-four, and both look plausible at a glance.

This translates the expression into a sentence and, more usefully, computes the next five times it will actually fire in your timezone. Seeing real dates is how you catch the classic mistakes: a job set for the 31st that skips most months, or one that quietly runs every minute of a chosen hour.

How to use this tool

  1. Type or paste the expression. Five fields separated by spaces; a leading seconds field is tolerated and ignored.
  2. Use a preset button if you want a known-good starting point to adapt.
  3. Read the sentence, then check the next five run times — that is what catches a misreading.
  4. Use the field table to see which value belongs to which position and its allowed range.

Worked example

Reading an inherited job

A server has 30 3 * * 0. It reads as 03:30 every Sunday, and the next-run list confirms it — so the backup people assumed was nightly runs weekly. That is the kind of thing the sentence alone would not have made obvious.

A job that skips months

0 0 31 * * looks like a monthly task. The next-run list shows it firing in months with 31 days only, skipping February, April, June, September and November entirely. Day 1 of the following month is almost always what was meant.

Common use cases

  • Understanding a crontab you have inherited
  • Checking a schedule before deploying it
  • Explaining a job's timing to someone else
  • Debugging a task that runs too often or not at all
  • Converting an informal schedule into a correct expression
  • Reviewing scheduled jobs during an audit

Common mistakes

  • Confusing */15 with 15 — */15 means every fifteenth minute. A bare 15 means at fifteen minutes past the hour — a quarter of the frequency.
  • Leaving a field as * by accident — * 2 * * * runs sixty times between 02:00 and 02:59, not once at two in the morning. That needs 0 2 * * *.
  • Both day fields set — When day-of-month and day-of-week are both restricted, classic cron runs when either matches, not both. That surprises almost everyone.
  • Forgetting the server's timezone — Cron uses the server's local time. A job written for 09:00 local runs at 09:00 UTC on a UTC server — check before assuming.

Frequently asked questions

What are the five fields?

In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12) and day of week (0–6, where 0 is Sunday). Some systems also accept 7 for Sunday and three-letter names like MON or JAN.

How do I run something every 15 minutes?

*/15 * * * * — at :00, :15, :30 and :45 of every hour. To offset it, list the minutes explicitly: 5,20,35,50 * * * *.

Can cron run more often than once a minute?

No. One minute is the finest resolution standard cron offers. For anything shorter, use a systemd timer, a process that sleeps in a loop, or a scheduler built for it.

Why does my job on the 31st not run every month?

Because only seven months have a 31st. For a monthly job use day 1 of the following month, or the 28th if it must be near the end.

What timezone do the next-run times use?

Your browser's timezone, so you can read them easily. Your server may well be on UTC — compare before trusting the times for a production schedule.

Are @daily and @reboot supported?

Not here; this reads the five-field numeric syntax. As an equivalent, @daily is 0 0 * * *, @hourly is 0 * * * * and @weekly is 0 0 * * 0.

Last updated 2026-09-26