Ttooleras

Translate cron expressions into plain English, calculate next run times, and explore common scheduling patterns.. Free, private — all processing in your browser.

*/5
minute
*
hour
*
day (month)
*
month
*
day (week)
Every 5 minutes
1.Fri, Jul 3121:45in 1 min
2.Fri, Jul 3121:50in 6 min
3.Fri, Jul 3121:55in 11 min
4.Fri, Jul 3122:00in 16 min
5.Fri, Jul 3122:05in 21 min
6.Fri, Jul 3122:10in 26 min
7.Fri, Jul 3122:15in 31 min
8.Fri, Jul 3122:20in 36 min
9.Fri, Jul 3122:25in 41 min
10.Fri, Jul 3122:30in 46 min
*any value*/nevery n (step)n,mspecific values (list)n-mrange from n to m
Advertisement

Paste a cron line you found in someone's crontab, a Kubernetes CronJob, or a CI config, and get it back in plain English — plus the next ten times it will run, so you know exactly what 0 3 * * 0 or */15 9-17 * * 1-5 actually does before you touch it. You can also edit it live or start from a preset.

This is the decoder for the moment you inherit a schedule and need to understand it fast, without mentally parsing five fields and hoping you got the day-of-week numbering right.

What the Crontab Guru can do

Cron to English

Paste an expression and see plain English explanation.

Next run times

Shows the next 10 times the schedule will execute.

English to cron

Describe your schedule in plain English and get the cron expression.

Visualization

Visual calendar/clock showing which days and hours the schedule covers.

Special strings

Recognizes @hourly, @daily, @weekly, @monthly, @yearly shortcuts.

6-field support

Extended cron with seconds for Quartz-style expressions.

Timezone aware

Next run times shown in your local timezone with UTC offset.

Warnings

Flags unusual patterns and common mistakes (day-of-week OR day-of-month logic).

Using the Crontab Guru

  1. 1

    Paste cron expression

    Drop a cron expression like \"0 9 * * 1-5\" into the input.

  2. 2

    See English translation

    The tool explains the schedule in natural language.

  3. 3

    Check next runs

    List of upcoming execution times with relative time markers.

  4. 4

    Visualize

    See the schedule on a calendar/clock grid for intuitive understanding.

  5. 5

    Modify or copy

    Tweak the expression and see results update live, or copy the current cron for use.

Common use cases for the Crontab Guru

System administration

  • Reading server crontabs: Quickly understand what each cron job does when auditing or debugging server-side scheduled tasks.
  • Writing new cron jobs: Verify a new cron expression matches your intended schedule before deploying.
  • Timezone verification: Confirm schedules execute at expected times when server timezone differs from user expectation.

CI/CD

  • GitHub Actions scheduled workflows: Write and verify cron expressions for workflow_dispatch or schedule triggers.
  • GitLab CI scheduled pipelines: Test cron syntax for scheduled pipelines and understand execution timing.
  • Kubernetes CronJobs: Write cron expressions for CronJob schedules with confidence.

Learning

  • Cron syntax tutorial: Learn cron step by step by experimenting with expressions and seeing explanations.
  • Debugging schedule bugs: When a cron job doesn’t run as expected, paste expression here to verify intent matches actual schedule.
  • Teaching new team members: Show how cron expressions translate to schedules during onboarding.

Crontab Guru — examples

Every weekday at 9 AM

Typical business-hours schedule.

Input
0 9 * * 1-5
Output
every weekday at 9:00 AM
next runs: Mon 9:00, Tue 9:00, Wed 9:00...

Every 15 minutes

Frequent polling schedule.

Input
*/15 * * * *
Output
every 15 minutes (at :00, :15, :30, :45)
next runs: current time + 0-15 minutes

Monthly

First day of month at midnight.

Input
0 0 1 * *
Output
first day of every month at midnight
next runs: Jun 1 00:00, Jul 1 00:00, Aug 1 00:00...

Shortcut

@daily equals full expression.

Input
@daily
Output
every day at midnight (0 0 * * *)
next runs: tomorrow 00:00, day after 00:00...

Day-of-week OR day-of-month

Surprise behavior.

Input
0 0 15 * 1
Output
on the 15th of every month AND every Monday at midnight
(OR logic — surprising to many users)

How it works

Reading a cron line, field by field: minute hour day-of-month month day-of-week. So 30 2 * * 1 reads as minute 30, hour 2, any day, any month, day-of-week 1 → "2:30am every Monday."

Day-of-week numbering is where people misread schedules. 0 (and sometimes 7) is Sunday, 1 is Monday, up to 6 for Saturday. * * * * 1-5 is Monday–Friday; * * * * 0,6 is the weekend. If a schedule seems off by a day, the day-of-week number is the usual culprit.

The operators you'll see: * (every), */n (every n — a step), a,b (a list), a-b (a range). Combinations like */15 9-17 * * 1-5 stack them: "every 15 minutes, between 9am and 5pm, Monday to Friday."

The classic gotcha to watch for: when *both* day-of-month and day-of-week are set (neither is *), standard cron runs when either matches. 0 0 13 * 5 is "midnight on the 13th or any Friday" — not "Friday the 13th." And remember the line runs in the server's timezone (usually UTC), not yours.

Troubleshooting

Misreading the day-of-week number

0 (and 7) is Sunday, 1 is Monday, 6 is Saturday. A schedule that looks like it runs on the wrong day is usually a day-of-week misread — 1 is Monday, not Sunday.

Reading a 6-field line as 5 fields

If the expression has six parts, the first is seconds (Quartz/Spring/some cloud). Interpreting it as standard 5-field cron shifts every field and gives a wrong reading. Count the fields first.

Assuming both day fields must match

When day-of-month and day-of-week are both set, cron fires when EITHER matches. 0 0 13 * 5 runs on the 13th OR on Fridays — a common source of 'why did it run today?'

Reading run times in your own timezone

Cron runs in the server's timezone, typically UTC. The preview here uses your local time for readability, but the real job fires on the server's clock — confirm the offset.

Not recognizing @ shortcuts

Lines like @daily, @weekly, or @reboot are aliases, not literal fields. @daily equals 0 0 * * *; @reboot runs once at startup. Translate the alias before reasoning about timing.

How it compares

Decoding vs writing. If you're reading an existing line, this explains it and previews its runs. If you're creating a schedule from scratch, the builder view and presets help you assemble one — same tool, either direction.

Standard cron vs the variants you might be reading. A plain 5-field line is Unix/Linux cron. If the line has *six* fields, it's a seconds-first format (Quartz, Spring, some cloud schedulers) and the fields mean something different — don't read it with 5-field assumptions. Some crontabs also use shortcuts like @daily, @hourly, or @reboot, which are named aliases for common 5-field expressions.

What the times mean here. The next-run preview is computed in your browser's local time so it's readable, but the job will fire in whatever timezone the server runs — verify the server's TZ before trusting a specific clock time.

Crontab Guru — FAQ

What does this cron expression mean?

Paste it above and you'll get a plain-English description plus the next ten run times. In short, the five fields are minute, hour, day-of-month, month, and day-of-week, read left to right.

What number is which day of the week?

0 is Sunday (7 also works in many crons), 1 is Monday, through 6 for Saturday. So 1-5 is weekdays and 0,6 is the weekend. Day-of-week misreads are the most common cron mistake.

What timezone will it run in?

The server's timezone, which is usually UTC. The next-run preview here shows your local time for readability, so compare against the server's clock before trusting an exact time.

Why does a both-days expression run more often than expected?

When day-of-month and day-of-week are both specified, standard cron fires when either one matches, not both. That OR behavior makes expressions like '0 0 13 * 5' run on the 13th and on every Friday.

What do @daily and @reboot mean?

They're named shortcuts. @daily is 0 0 * * * (midnight every day), @hourly is 0 * * * *, and @reboot runs once when the system starts. They're aliases for common schedules.

The line has six fields — why?

That's a seconds-first format used by Quartz, Spring, and some cloud schedulers, where the extra leading field is seconds. It isn't standard Unix cron; read it as six fields, not five.

Further reading

Advertisement

Learn more

Explore more tools

200+ free tools that run in your browser.

Browse all tools →