What do the five cron fields mean, 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), in that fixed order. A * in any field means "every value" for that field, and combining a day-of-month value with a day-of-week value other than * means the job runs when either condition matches, not both.

Why wrap the command in flock?

If a job normally finishes in a few seconds but occasionally runs long (a slow network call, a database hiccup), the next scheduled run can start before the previous one finished, causing two copies to run concurrently and potentially corrupt shared state. `flock -n -c "command"` acquires an exclusive lock and skips the run entirely (-n, non-blocking) if another instance already holds it.

What does the log-redirection toggle add?

It appends `>> /path/to/log 2>&1` to the command, which appends both standard output and standard error to a log file instead of letting cron's default behavior (usually emailing output to the crontab owner, if mail is even configured) silently swallow or misroute it.

Where do I put the generated line?

Run `crontab -e` to open your user crontab in an editor and paste the line in, or for a system-wide job, add it to a file under /etc/cron.d/ (which additionally requires a username field between the schedule and the command).

Crontab Generator - Cron Schedule Builder with Presets

Overview

Introduction

Cron's five-field schedule syntax is compact but easy to get subtly wrong, especially the interaction between the day-of-month and day-of-week fields, and it's common to forget locking or logging around a scheduled command until a job silently runs twice or fails silently.

This tool builds a complete crontab line from named fields and a few common presets, with optional flock locking and log redirection wrapped around your command automatically.

What Is Crontab Generator?

A cron schedule builder covering all five standard fields (minute, hour, day of month, month, day of week), a set of common presets (every 5/15 minutes, hourly, daily at 2am, weekly, monthly), and two optional wrappers: flock-based locking and stdout/stderr log redirection.

The output is a single ready-to-paste crontab line, in the exact five-fields-then-command format crontab -e and /etc/cron.d/ files expect.

How Crontab Generator Works

Each of the five fields is validated against cron's basic syntax (digits, *, /, -, and , only) before being joined with the command into one line, catching an invalid field before it silently fails (or worse, runs at an unintended time) once installed.

When flock locking is enabled, the command is wrapped as `flock -n <lockfile> -c "<command>"`; when log redirection is enabled, `>> <logfile> 2>&1` is appended after that, so both wrappers combine correctly regardless of which are toggled on.

When To Use Crontab Generator

Use it whenever you're adding a new scheduled job and want the five-field schedule right on the first try, especially for schedules that aren't a simple 'every N minutes' pattern.

It's also useful for jobs that run occasionally (backups, batch imports) where you specifically want protection against an overlapping run via flock, and where you want output actually saved somewhere instead of relying on cron's mail-based default.

Often used alongside systemd Service Generator and Bash Script Generator.

Features

Advantages

Validates each field's syntax before you install it, catching a stray character that would otherwise fail cron silently.
Bundles flock locking and log redirection as simple toggles instead of requiring you to remember the exact wrapper syntax.
Includes presets for the schedules most jobs actually use, without needing to work out the five-field combination from scratch.

Limitations

Only validates field syntax, not semantic correctness, e.g. it won't catch "31" in day-of-month for a month that never has 31 days.
Doesn't install the crontab entry for you, since that requires access to the actual system's crontab or /etc/cron.d/, which a browser tool can't reach.
The day-of-month/day-of-week OR-interaction (when both are restricted to something other than *) is a cron quirk this tool doesn't specifically flag, review the combination if you're using both.

Examples

A nightly backup job with locking and logging

Input

preset: Daily at 2am, command: /usr/local/bin/backup.sh, useFlock: true, flockPath: /tmp/backup.lock, useLogRedirect: true, logPath: /var/log/backup.log

Output

0 2 * * * flock -n /tmp/backup.lock -c "/usr/local/bin/backup.sh" >> /var/log/backup.log 2>&1

flock prevents a slow backup from overlapping with the next night's run, and all output is appended to a log file instead of relying on cron's mail delivery.

Best Practices & Notes

Best Practices

Wrap any job that could occasionally run long in flock, so a slow run never overlaps with the next scheduled invocation.
Always redirect output to a log file for unattended jobs, cron's default mail-based reporting is often not configured on modern servers and failures go unnoticed.
Use absolute paths for both the command and any lock/log file paths, cron jobs run with a minimal environment and a much shorter PATH than an interactive shell.

Developer Notes

Field validation uses a permissive regex (/^[0-9*/,-]+$/) matching cron's core POSIX syntax (values, ranges, steps, and lists) without attempting to fully validate named ranges like month abbreviations (JAN-DEC) or weekday names (MON-SUN), which some cron implementations (notably Vixie cron) support as an extension but aren't part of the strict POSIX five-field grammar. The flock wrapper always uses -n (non-blocking) so a still-running previous job causes the new invocation to simply exit rather than queue and pile up.

Crontab Generator Use Cases

Scheduling a recurring backup, cleanup, or batch-processing script with protection against overlapping runs
Building a precise custom schedule (e.g. 'every 15 minutes during business hours') that doesn't fit a simple preset
Producing a crontab line with logging built in for a job that previously failed silently

Common Mistakes

Forgetting that cron runs with a minimal PATH and environment, using a bare command name instead of an absolute path often fails even though it works fine in an interactive shell.
Omitting log redirection and assuming failures will show up somewhere, on most modern servers cron's mail delivery isn't configured at all.
Not locking a job that occasionally runs long, leading to two overlapping instances that can corrupt shared state or double up side effects like sending duplicate emails.

Tips

Test the underlying command manually first, cron issues are frequently really PATH or environment differences rather than a scheduling problem.
For anything more complex than a simple recurring command, consider a systemd timer (paired with the systemd Service Generator) instead, which offers better logging via journalctl and clearer dependency handling.

Crontab Generator