Everything runs on your machine — your input is processed right here in your browser and never uploaded to any server.

Cron Parser

About this tool

Cron expressions pack a whole schedule into five terse fields, powerful and notoriously easy to misread. The difference between 0 5 * * 1 and 5 0 * * 1 is Monday at 5 a.m. versus just after midnight, often unnoticed until a backup runs at the wrong hour. This parser removes the guesswork: type an expression and it explains the schedule in plain English and lists the next five run times in your local timezone.

It accepts standard five-field expressions plus shortcuts like @hourly and @daily, preset chips give you a correct starting point to adapt, and invalid expressions get an inline error message instead of silent failure. It is a quick sanity check before you commit a crontab change, edit a Kubernetes CronJob or configure a CI schedule.

How to use

  1. Type your cron expression, using the five-field format or a shortcut like @hourly.
  2. Or click a preset chip to load a common schedule and adapt it.
  3. Read the plain-English explanation to confirm the expression means what you intended.
  4. Check the next 5 run times, shown in your local timezone.
  5. If the expression is invalid, follow the inline error message to fix the offending field.

Parsing an expression and projecting its run times happens entirely in your browser; the page never asks a server what your schedule means. The expressions you test, which may describe internal jobs and maintenance windows, remain private to your device.

Frequently asked questions

What order are the five fields in?

From left to right: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, with 0 meaning Sunday). A common mistake is swapping the first two, so 30 2 * * * means 02:30 every day, not every second hour.

What happens if I set both day-of-month and day-of-week?

In standard cron they combine with OR semantics: the job runs when either field matches. So 0 9 1 * 1 fires at 9 a.m. on the 1st of every month and on every Monday, not only on Mondays that fall on the 1st.

Why do the predicted times differ from when my server runs the job?

This tool shows runs in your local timezone, but cron daemons use the server's clock, often UTC. If the server is in a different zone, the same expression fires at a different local hour for you, so check the server's timezone before blaming the expression.