When working with cron expressions, the minute field offers several ways to specify execution frequency. While they may seem similar at first glance, 0/1, 1/1, and * have distinct behaviors that affect job scheduling precision.

The simplest form represents every possible value in the field:

* * * * * command  # Runs every minute

This is equivalent to specifying 0-59 in the minute field. No offset or division is applied.

The slash indicates steps through a range. The general format is start/step:

0/1 * * * * command  # Runs at :00, :01, :02,...:59
1/1 * * * * command  # Runs at :01, :02,...:59 (skips :00)

Consider these real-world scenarios:

# Database backup every minute starting at top of hour
0/1 * * * * /usr/bin/backup.sh

# Monitoring script with 1-minute offset
1/1 * * * * /usr/bin/monitor.sh

# High-frequency log rotation (every minute)
* * * * * /usr/bin/rotate-logs.sh

Important behavioral notes:

• 0/1 and * both execute at :00, but differ in implementation
• 1/1 creates a 1-minute offset pattern
• Some cron implementations treat */1 as equivalent to *

While POSIX defines the standard, variations exist:

# Vixie cron (common on Linux):
0/5 * * * *  # :00, :05,...:55

# Solaris cron:
*/5 * * * *  # May behave differently

Cron expressions are widely used in scheduling tasks, but subtle differences in syntax can lead to unexpected behavior. Let's examine the three variants:

0/1 * * * *  // Runs at every minute (same as *)
1/1 * * * *  // Also runs every minute, but starts at 1
* * * * *    // The classic wildcard for every minute

The 0/1 syntax explicitly starts counting from 0, while 1/1 begins at 1. In practice for minutes, both will trigger every minute just like *, but the starting point matters in other fields:

0/15 * * * *  // Runs at :00, :15, :30, :45
15/15 * * * * // Runs at :15, :30, :45 (skips :00)

These differences become crucial when dealing with:

• Hourly jobs that must run at specific intervals
• Monthly reports that should skip certain days
• Distributed systems where exact timing matters

For example, in a distributed lock scenario:

# Safe approach for distributed locks
*/5 * * * *  # Could cause collisions
5/5 * * * *  # Staggered start reduces collision risk

When in doubt:

1. Use 0/x for predictable interval-based scheduling
2. Reserve * for simple "run always" cases
3. Test your cron expressions with tools like crontab.guru