Cron Expression Parser & Validator
Pricing
Pay per event
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
Actor stats
0
Bookmarked
2
Total users
1
Monthly active users
2 days ago
Last modified
Categories
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:
| Field | Type | Description |
|---|---|---|
expression | string | The original cron expression |
isValid | boolean | Whether the expression is syntactically valid |
description | string | Human-readable description (e.g., "Every 5 minutes") |
fieldCount | number | Number of fields (5 or 6) |
fieldSeconds | string | Seconds field (6-field format only) |
fieldMinute | string | Minute field value |
fieldHour | string | Hour field value |
fieldDayOfMonth | string | Day of month field value |
fieldMonth | string | Month field value |
fieldDayOfWeek | string | Day of week field value |
nextRun1...nextRun10 | string | ISO 8601 timestamps for next scheduled runs |
nextRuns | array | Full array of next run timestamps |
timezone | string | Timezone used for calculations |
error | string | Error 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.
| Event | Cost |
|---|---|
| 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)
- Go to Cron Expression Parser on the Apify Store
- Click Try for free
- In the Cron Expressions field, paste your expressions (one per line)
- Set Next run count (default: 5) and Timezone (default: UTC)
- Click Start and wait for the run to finish
- Click Results to view the parsed output table
Typical workflow
- Collect cron expressions from your crontabs, CI configs, or database
- Paste them all into the Cron Expressions field
- Set your desired timezone for accurate local times
- Export results to JSON or CSV for documentation or analysis
⚙️ Input parameters
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
expressions | string[] | Yes | — | List of cron expressions to parse |
nextRunCount | number | No | 5 | Number of next run times to calculate (1–20) |
timezone | string | No | UTC | IANA timezone name (e.g., America/New_York) |
referenceDate | string | No | now | ISO 8601 anchor date for calculating next runs |
Cron expression formats
5-field (standard):
* * * * *│ │ │ │ └─ Day of week (0–7, 0 and 7 = Sunday)│ │ │ └─── Month (1–12)│ │ └───── Day of month (1–31)│ └─────── Hour (0–23)└───────── Minute (0–59)
6-field (with seconds):
* * * * * *│ │ │ │ │ └─ Day of week│ │ │ │ └─── Month│ │ │ └───── Day of month│ │ └─────── Hour│ └───────── Minute└─────────── Second (0–59)
Common cron expression examples
| Expression | Description |
|---|---|
* * * * * | Every minute |
*/5 * * * * | Every 5 minutes |
0 * * * * | Every hour (at :00) |
0 9 * * * | Every day at 09:00 |
0 9 * * 1-5 | Weekdays at 09:00 |
0 0 * * 0 | Every 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-5 | Every 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 schedulesrun: |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 ApifyClientclient = 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 runcurl -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.
🔗 Related actors
- JWT Decoder & Validator — Decode and validate JWT tokens in bulk, extract claims and check expiration status
- Domain Availability Checker — Check if domain names are available for registration in bulk
- DMARC Record Checker — Validate DMARC DNS records for email domains in bulk
- SPF Record Checker — Check SPF email authentication records for domains
- Robots & Sitemap Analyzer — Parse and analyze robots.txt and sitemap files for any website