Cron Schedule Builder

What This Prompt Does

This prompt translates conversational descriptions of task schedules (e.g. “every Tuesday and Thursday at 3:15 AM”) into a standard 5-field crontab syntax. It provides precise calculations, explains the meaning of each field, and calls out potential timezone or server offset considerations.

System Prompt

You are a senior systems architect. Translate the plain-English schedule description into a standard 5-field crontab expression.
For every generation:
1. Provide the exact crontab string (e.g. "15 3 * * 2,4").
2. Break down each field: minute, hour, day of month, month, and day of week.
3. Detail any edge cases, such as behavior on month boundary dates.
4. Recommend best practices, such as shifting schedules slightly to avoid load spikes.

User Prompt Template

Translate this schedule description to a standard crontab entry:
{CRON_DESCRIPTION}
(e.g., "every other Sunday at midnight", "daily at 2:00 AM and 2:00 PM")

Target server timezone configuration: {TIMEZONE}
(e.g., "UTC", "America/New_York")

Provide field breakdown and execution examples.

Example Output

Crontab Expression:
15 3 * * 2,4

Breakdown:
- Minute: 15 (at 15 minutes past the hour)
- Hour: 3 (at 3:00 AM)
- Day of Month: * (every day of the month)
- Month: * (every month)
- Day of Week: 2,4 (Tuesday and Thursday)

When to Use This

This prompt is handy whenever you need a cron expression for a specific schedule and don’t want to work through cron’s terse five-field syntax by hand — particularly for schedules with less common patterns, like “every weekday except the last day of the month” or “every 15 minutes during business hours only.”

Tips for Best Results

• Describe the schedule in plain language as specifically as possible, including timezone expectations, since cron expressions themselves are timezone-agnostic and rely on the system or scheduler’s configured timezone, a common source of off-by-hours bugs.
• Ask the model to explain each field of the generated expression, not just provide the raw cron string, so you can verify it actually matches your intended schedule rather than trusting it blindly.
• Test generated expressions against a cron expression validator or a dry-run mode in your scheduler before relying on them in production, since a single misplaced field can produce a schedule that runs far more or less often than intended.

Documenting the plain-language intent alongside the generated cron expression in code comments saves the next person from having to reverse-engineer the schedule’s purpose from the cryptic five-field syntax alone.