CCronExplain
Get CronExplain

CronExplain/Guides

How to Make a Crontab Entry Step-by-Step

Learn to create valid cron schedules using CronExplain's visual builder and plain-English preview to ensure your jobs run exactly when intended.

October 22, 2026 · 4 min read

A cron expression is a five-field string that tells the system when to run a command. To create one, specify the minute, hour, day, month, and weekday in that order, separated by spaces. For example, 30 9 * * 1-5 runs a task at 9:30 AM every Monday through Friday.

Understanding Cron Field Structure

The standard cron format uses five fields. Each field filters time differently, and the order matters because cron reads left to right. If you get the order wrong, your job might run at midnight instead of morning, or skip weekends entirely.

The fields are:

  1. Minute (0–59)
  2. Hour (0–23)
  3. Day of month (1–31)
  4. Month (1–12)
  5. Day of week (0–7, where both 0 and 7 are Sunday)

Wildcards are common. An asterisk * means "every value." A comma-separated list like 1,15,30 means exactly those values. A range like 1-5 means every value from start to end inclusive. Step values like */10 mean every tenth unit starting from zero.

Consider the expression 0 */2 * * *. This runs every two hours on the hour. The first field 0 locks the minute to zero. The second field */2 steps through hours 0, 2, 4, and so on. The remaining asterisks accept any day, month, or weekday. This is useful for health checks that don’t need minute-level precision but should not drift across hours.

Using the Visual Builder for Precision

Writing cron syntax from memory is error-prone. A visual builder lets you select values from dropdowns for minute, hour, day, month, and weekday, then generates the correct string automatically. This eliminates common mistakes like swapping hour and minute fields or misunderstanding how ranges work.

When you build an expression visually, you see the result update live. For instance, selecting minute 30, hour 9, day *, month *, and weekday 1-5 produces 30 9 * * 1-5. You can verify the logic before copying the string into your configuration file. This approach is faster than debugging a typo in a text editor, especially when you are managing multiple environments with different timezone requirements.

You can also start from common patterns. If you need a job to run every five minutes, selecting the predefined pattern saves time compared to typing */5 * * * * manually. Once generated, the expression is ready to paste into your crontab file, GitHub Actions workflow, or Kubernetes CronJob manifest.

Previewing Next Fire Times

Confirming when a cron expression actually fires prevents surprises. The next-fire preview shows the upcoming ten execution times in your local timezone. This immediate feedback confirms whether your logic matches your intent.

Take the backup example: 30 9 * * 1-5. If you paste this into a preview tool, you see the next ten instances. Suppose today is Tuesday, November 12, 2024. The preview shows:

Notice that Saturday and Sunday are skipped. If you expected weekend runs, you would adjust the weekday field to * or 0-6. Seeing these dates immediately allows you to tweak the expression without waiting for the next scheduled run. You can use CronExplain to generate these previews instantly, ensuring the schedule aligns with your operational needs before you commit the change.

Handling Timezone and Daylight Savings

Cron jobs typically run in the server’s local timezone. If your server is in UTC and you live in Eastern Time, a job set for 0 9 * * * will run at 4:00 AM your time during standard time and 5:00 AM during daylight saving time, depending on how the system handles the offset.

Most modern systems use the system timezone for cron calculations. When daylight saving time begins, clocks spring forward. A cron job set for 0 2 * * * might skip a run if 2:00 AM does not exist that day, or run twice if clocks fall back. To avoid ambiguity, specify minutes and hours that are less likely to conflict with transition windows, or configure your server’s timezone explicitly.

If you manage distributed teams, pinning a fixed timezone helps. For example, if your team is coordinated in UTC, set all crons to UTC regardless of individual local times. This ensures everyone sees the same schedule. In Kubernetes, you can set the TZ environment variable in the CronJob spec. In traditional crontab files, ensure the system timezone is configured correctly at the OS level.

Common Pitfalls and Fixes

Small errors in cron syntax cause silent failures. Here are frequent issues and how to resolve them.

Minute and Hour Swap Writing 9 30 * * * instead of 30 9 * * * means minute 9, hour 30. Hour 30 is invalid, so the job may never run or run unexpectedly. Always check the order: Minute Hour Day Month Weekday.

Weekday Confusion Sunday can be 0 or 7. Some systems treat them identically, others differ. To run every day including weekends, use *. To run Monday through Friday, use 1-5. Avoid mixing numeric and name formats unless you are certain of your parser’s support.

Overlapping Schedules If you have two jobs that both run at 0 * * * *, they compete for resources. Stagger them by changing minutes: one at 0, the other at 15. This prevents CPU spikes at the top of every hour.

Missing Trailing Newlines Some editors require a newline after the last cron entry. If your job does not run, check that the file ends with a blank line. This is especially common when editing via command-line tools.

By focusing on field order, timezone consistency, and clear scheduling windows, you can create reliable cron entries. Use visual tools to verify logic, then deploy with confidence knowing the timing matches your operational requirements.

Do it in CronExplain

Everything in this guide works in the browser — open the tool and try it on your own input.

Open CronExplain →

Questions people also ask

What is the difference between 5-field and 6-field cron?

The standard format uses five fields (minute, hour, day, month, weekday), while some systems like Quartz Scheduler use six fields by adding seconds as the first field. Use the five-field format for standard Linux/macOS crontabs and the six-field format only if your specific scheduler requires it.

How do I handle daylight savings time in cron?

Cron typically respects the server's configured timezone, so ensure your OS timezone is set correctly to align with your local expectations. To avoid ambiguity during clock transitions, schedule jobs outside the 1:00 AM to 3:00 AM window or pin your server timezone to UTC if you need consistent absolute timing.

Can I use nicknames like @daily instead of numbers?

Yes, most modern cron implementations support nicknames such as @hourly, @daily, @weekly, and @monthly to simplify common schedules. These shortcuts are equivalent to specific numeric expressions, like @daily being identical to 0 0 * * *, and are widely supported in Linux and macOS environments.

Why does my cron job not run on Sundays?

Your weekday field likely specifies a range like 1-5, which excludes Sunday (represented as 0 or 7). To include Sundays, change the weekday field to * for every day or explicitly add 0 or 7 to your list, such as 1-5,7.

More guides