Cron Expression Parser & Validator avatar

Cron Expression Parser & Validator

Pricing

Pay per event

Go to Apify Store
Cron Expression Parser & Validator

Cron Expression Parser & Validator

Parse, validate, and explain cron expressions in plain English. Shows the next N scheduled run times, provides a full field-by-field breakdown, and supports both 5-field standard and 6-field (with seconds) formats. Ideal for debugging schedulers and CI/CD pipeline configuration.

Pricing

Pay per event

Rating

0.0

(0)

Developer

Stas Persiianenko

Stas Persiianenko

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

2 days ago

Last modified

Share

Parse, validate, and explain cron expressions in bulk. Turn cryptic cron syntax like */5 * * * * into human-readable descriptions like "Every 5 minutes", calculate the next N scheduled run times, and get a full field-by-field breakdown — all via a simple API or no-code UI.


🔍 What does it do?

Cron expressions are the standard format for scheduling recurring tasks — used in Linux cron jobs, GitHub Actions, Kubernetes CronJobs, AWS EventBridge, and dozens of other platforms. But reading cron syntax is notoriously tricky: 30 6 1 * * doesn't obviously mean "At 06:30 on day-of-month 1".

This actor solves that. Give it a list of cron expressions and it returns:

  • Validation — is the expression syntactically correct?
  • 📖 Human-readable description — plain English explanation of when it fires
  • 🗓️ Next N run times — calculated in any timezone, relative to any reference date
  • 🧩 Field breakdown — each field (minute, hour, day, month, weekday) labeled separately
  • Error details — for invalid expressions, explains exactly what's wrong

Supports both 5-field (standard) and 6-field (with seconds) cron formats.


👥 Who is it for?

DevOps engineers and SREs who need to audit or document scheduled jobs across a fleet of servers, Kubernetes clusters, or CI/CD pipelines. Paste all your cron schedules and get a human-readable audit in seconds.

Backend developers building scheduling systems who want to validate cron expressions in batch before storing them in a database — catch syntax errors before they cause silent failures at 3 AM.

Data engineers managing pipelines with complex cron schedules across multiple time zones. See exactly when jobs fire in UTC, New York, Tokyo, or any IANA timezone.

QA and documentation teams who need to document what each scheduled task does without needing a cron expert on staff. Feed expressions in, get plain-English descriptions out.

Automation builders using no-code tools like Make, Zapier, or n8n who want to understand cron expressions they didn't write before using them in production workflows.


💡 Why use this actor?

There are browser-based tools like crontab.guru for checking cron expressions one at a time. This actor gives you batch processing via API — parse hundreds of expressions in a single run, integrate results into your automation pipelines, and export to JSON/CSV.

Key advantages:

  • Batch processing — parse dozens or hundreds of expressions in one run
  • Timezone-aware — next run times calculated in any IANA timezone
  • Reference date support — calculate future schedules from any anchor date, not just "now"
  • API-first — integrate directly into your CI/CD pipelines or automation workflows
  • Both 5 and 6 field formats — handles standard cron and extended cron with seconds field
  • Structured output — clean JSON with every field labeled, ready for downstream processing

📊 Output data

Each cron expression produces one dataset item with the following fields:

FieldTypeDescription
expressionstringThe original cron expression
isValidbooleanWhether the expression is syntactically valid
descriptionstringHuman-readable description (e.g., "Every 5 minutes")
fieldCountnumberNumber of fields (5 or 6)
fieldSecondsstringSeconds field (6-field format only)
fieldMinutestringMinute field value
fieldHourstringHour field value
fieldDayOfMonthstringDay of month field value
fieldMonthstringMonth field value
fieldDayOfWeekstringDay of week field value
nextRun1...nextRun10stringISO 8601 timestamps for next scheduled runs
nextRunsarrayFull array of next run timestamps
timezonestringTimezone used for calculations
errorstringError message for invalid expressions (null if valid)

💰 How much does it cost to parse cron expressions?

Pricing uses Pay Per Event (PPE) — you only pay for what you actually process, with no minimum charge beyond the $0.01 start fee.

EventCost
Actor start$0.01 (once per run)
Per expression parsed$0.00115 (FREE plan)

Example costs:

  • Parse 10 expressions → ~$0.012 total
  • Parse 100 expressions → ~$0.025 total
  • Parse 1,000 expressions → ~$0.115 total + $0.01 start = ~$0.125

Free plan estimate: Apify's free plan includes $5/month in platform credits, enough to parse roughly 4,000 expressions per month at no charge.

Paid plan users (BRONZE through DIAMOND) get tiered discounts — the more you process, the lower the per-expression cost. See Apify pricing for tier details.


🚀 How to use it

Using the Apify Console (no code)

  1. Go to Cron Expression Parser on the Apify Store
  2. Click Try for free
  3. In the Cron Expressions field, paste your expressions (one per line)
  4. Set Next run count (default: 5) and Timezone (default: UTC)
  5. Click Start and wait for the run to finish
  6. Click Results to view the parsed output table

Typical workflow

  1. Collect cron expressions from your crontabs, CI configs, or database
  2. Paste them all into the Cron Expressions field
  3. Set your desired timezone for accurate local times
  4. Export results to JSON or CSV for documentation or analysis

⚙️ Input parameters

ParameterTypeRequiredDefaultDescription
expressionsstring[]YesList of cron expressions to parse
nextRunCountnumberNo5Number of next run times to calculate (1–20)
timezonestringNoUTCIANA timezone name (e.g., America/New_York)
referenceDatestringNonowISO 8601 anchor date for calculating next runs

Cron expression formats

5-field (standard):

* * * * *
│ │ │ │ └─ Day of week (07, 0 and 7 = Sunday)
│ │ │ └─── Month (112)
│ │ └───── Day of month (131)
│ └─────── Hour (023)
└───────── Minute (059)

6-field (with seconds):

* * * * * *
│ │ │ │ │ └─ Day of week
│ │ │ │ └─── Month
│ │ │ └───── Day of month
│ │ └─────── Hour
│ └───────── Minute
└─────────── Second (059)

Common cron expression examples

ExpressionDescription
* * * * *Every minute
*/5 * * * *Every 5 minutes
0 * * * *Every hour (at :00)
0 9 * * *Every day at 09:00
0 9 * * 1-5Weekdays at 09:00
0 0 * * 0Every Sunday at midnight
30 6 1 * *1st of each month at 06:30
0 0 1 1 *Every January 1st at midnight
*/15 9-17 * * 1-5Every 15 min, 9–5, weekdays
0 0 0 * * *Midnight daily (6-field with seconds)

📤 Output example

{
"expression": "0 9 * * 1-5",
"isValid": true,
"description": "At 09:00, Monday through Friday",
"fieldCount": 5,
"fieldSeconds": null,
"fieldMinute": "0",
"fieldHour": "9",
"fieldDayOfMonth": "*",
"fieldMonth": "*",
"fieldDayOfWeek": "1-5",
"nextRun1": "2024-06-03T13:00:00.000Z",
"nextRun2": "2024-06-04T13:00:00.000Z",
"nextRun3": "2024-06-05T13:00:00.000Z",
"nextRun4": "2024-06-06T13:00:00.000Z",
"nextRun5": "2024-06-07T13:00:00.000Z",
"nextRun6": null,
"nextRun7": null,
"nextRun8": null,
"nextRun9": null,
"nextRun10": null,
"nextRuns": [
"2024-06-03T13:00:00.000Z",
"2024-06-04T13:00:00.000Z",
"2024-06-05T13:00:00.000Z",
"2024-06-06T13:00:00.000Z",
"2024-06-07T13:00:00.000Z"
],
"timezone": "America/New_York",
"error": null
}

Invalid expression output:

{
"expression": "invalid expression here",
"isValid": false,
"description": null,
"fieldCount": 3,
"fieldSeconds": null,
"fieldMinute": null,
"fieldHour": null,
"fieldDayOfMonth": null,
"fieldMonth": null,
"fieldDayOfWeek": null,
"nextRun1": null,
"nextRuns": [],
"timezone": "UTC",
"error": "Invalid cron expression: expected 5 or 6 fields, got 3"
}

💡 Tips and tricks

Auditing cron jobs on a Linux server:

$crontab -l | grep -v '^#' | grep -v '^$' | awk '{print $1" "$2" "$3" "$4" "$5}' > crons.txt

Then paste the contents into the Cron Expressions field.

Checking all crontabs at once:

$for user in $(cut -d: -f1 /etc/passwd); do crontab -u $user -l 2>/dev/null; done

Validating Kubernetes CronJob schedules: Kubectl output includes the schedule field — parse it in bulk before deploying to production.

AWS EventBridge uses rate expressions (rate(5 minutes)) not cron — convert them to cron format first.

GitHub Actions cron schedules run in UTC. Use timezone UTC when calculating next runs for GitHub Actions.

Day of week values: Both 0 and 7 mean Sunday. You can also use names: sun, mon, tue, wed, thu, fri, sat.

Month values can use names: jan, feb, mar, apr, may, jun, jul, aug, sep, oct, nov, dec.

Step values like */5 mean "every 5 units" — */5 in the minute field means every 5 minutes, */2 in the hour field means every 2 hours.

Ranges like 9-17 mean "from 9 to 17 inclusive". Combined: */30 9-17 * * 1-5 = every 30 minutes during business hours on weekdays.


🔌 Integrations

GitHub Actions: validate schedules before deploying

Run this actor as part of your CI pipeline to validate all cron schedules in your repo before they reach production:

- name: Validate cron schedules
run: |
node -e "
const { ApifyClient } = require('apify-client');
const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
// Extract cron expressions from workflow files and validate them
"

Make (formerly Integromat): parse cron from database

Use the Apify HTTP module to call this actor via API, then route valid/invalid expressions to different branches of your scenario. Perfect for validation workflows before writing to a scheduling database.

n8n: cron audit workflow

Connect this actor to an n8n Code node that reads your application's scheduled job table, runs validation, and posts invalid expressions to a Slack channel for immediate review.

Zapier: schedule change notifications

When someone changes a cron expression in your system (detected via webhook), run it through this actor to get the human-readable description and include it in the change notification email — so reviewers immediately understand what changed.

Spreadsheet export

Use the CSV download from the Results tab to build a cron schedule inventory spreadsheet. Map expression → description → next run times into columns for easy documentation.


🤖 API usage

Node.js

import { ApifyClient } from 'apify-client';
const client = new ApifyClient({ token: 'YOUR_APIFY_API_TOKEN' });
const run = await client.actor('automation-lab/cron-expression-parser').call({
expressions: ['*/5 * * * *', '0 9 * * 1-5', '30 6 1 * *'],
nextRunCount: 5,
timezone: 'America/New_York',
});
const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const item of items) {
console.log(`${item.expression}: ${item.description}`);
if (item.isValid) {
console.log(` Next run: ${item.nextRun1}`);
} else {
console.log(` Error: ${item.error}`);
}
}

Python

from apify_client import ApifyClient
client = ApifyClient(token="YOUR_APIFY_API_TOKEN")
run = client.actor("automation-lab/cron-expression-parser").call(run_input={
"expressions": ["*/5 * * * *", "0 9 * * 1-5", "30 6 1 * *"],
"nextRunCount": 5,
"timezone": "America/New_York",
})
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
print(f"{item['expression']}: {item.get('description', item.get('error'))}")
if item["isValid"]:
print(f" Next run: {item['nextRun1']}")

cURL

# Start the actor run
curl -X POST \
"https://api.apify.com/v2/acts/automation-lab~cron-expression-parser/runs?token=YOUR_APIFY_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"expressions": ["*/5 * * * *", "0 9 * * 1-5", "30 6 1 * *"],
"nextRunCount": 5,
"timezone": "UTC"
}'
# Get results (replace RUN_ID and DATASET_ID from the response above)
curl "https://api.apify.com/v2/datasets/DATASET_ID/items?token=YOUR_APIFY_API_TOKEN"

Use with Claude AI (MCP)

This actor is available as a tool in Claude AI through the Model Context Protocol (MCP). Add it to Claude Desktop, Cursor, Windsurf, or any MCP-compatible client.

Setup for Claude Code

$claude mcp add --transport http apify "https://mcp.apify.com"

Setup for Claude Desktop, Cursor, or VS Code

Add this to your MCP config file:

{
"mcpServers": {
"apify": {
"url": "https://mcp.apify.com"
}
}
}

Example prompts

  • "Parse these cron expressions and explain when each one fires: */5 * * * *, 0 9 * * 1-5, 30 6 1 * *."
  • "What does 0 0 1,15 * * mean and when will it run next in America/New_York timezone?"
  • "Validate all the cron schedules from my Kubernetes CronJob configs and flag any invalid ones."

Learn more in the Apify MCP documentation.


⚖️ Legality

This actor processes cron expression strings — it performs no web scraping and makes no network requests to third-party services. All parsing is done locally using the cron-parser and cronstrue npm packages.

There are no legal concerns with using this actor. It is a pure computation utility.


❓ FAQ

Q: What cron formats are supported? A: Standard 5-field cron (minute hour day month weekday) and 6-field cron with a leading seconds field (second minute hour day month weekday). The Quartz scheduler's 6-field format (with seconds and optional years) is not supported.

Q: Why do next run times show in UTC even when I set a timezone? A: The nextRun1 through nextRun10 fields are always stored in ISO 8601 UTC format for consistency. The timezone you set affects when the schedule fires — for example, 0 9 * * 1-5 in America/New_York fires at 09:00 New York time, which appears as 13:00 UTC in summer (UTC-4). Convert to local time with your preferred date library.

Q: Does this handle daylight saving time transitions? A: Yes. The cron-parser library fully handles DST transitions using IANA timezone data. Schedules are calculated correctly across spring-forward and fall-back dates.

Q: What's the difference between 0 0 * * * and 0 0 0 * * *? A: 0 0 * * * is a 5-field expression meaning "at 00:00 every day" (midnight). 0 0 0 * * * is 6-field format where the first field is seconds — it means "at 0 seconds, 0 minutes, 0 hours every day", which is the same thing. Both produce daily midnight runs.

Q: Can I use special strings like @daily or @hourly? A: No — these are non-standard cron aliases (supported by Vixie cron and some platforms). This actor requires explicit numeric/wildcard cron syntax. Convert @daily to 0 0 * * *, @hourly to 0 * * * *, @weekly to 0 0 * * 0, and @monthly to 0 0 1 * *.

Q: The actor parsed my expression but the description seems wrong. What should I do? A: The human-readable description is generated by the cronstrue library. For complex expressions with multiple ranges and steps, the description may be simplified. The next run times calculated by cron-parser are the authoritative source — trust those over the description for precise scheduling.

Q: I'm getting "Invalid explicit day of month definition" for 0 0 30 2 *. Is this a bug? A: No — February 30th doesn't exist. The actor correctly rejects expressions that can never fire. This is caught at parse time to help you spot configuration mistakes.