What Cron Schedule Audit does
Cron Schedule Audit MCP server checks whether a cron schedule means what its author expects and whether daylight-saving transitions can change its behavior. It returns plain-English explanations alongside validation results, making it suitable for reviewing scheduled jobs before they are deployed.
The server focuses on three recurring sources of cron mistakes. It warns that restricted day-of-month and day-of-week fields use OR semantics in POSIX cron, rather than AND semantics. It identifies schedules that run every minute and may be unintended, and it points out day-of-month values such as 29, 30, or 31 that are absent in some months. It also highlights schedules in the 1–3am range as candidates for further DST review.
How it works
Cron Schedule Audit uses the platform's own IANA timezone data rather than a separate timezone package. Its DST-aware calculations model local scheduled times against real timezone offsets, allowing the server to distinguish between times that exist once, do not exist during a spring-forward gap, or occur twice during a fall-back overlap.
The validate_cron_expression tool performs syntax and semantic checks and explains the expression's meaning. get_next_fire_times returns the next requested number of executions. A local time in a spring-forward gap is marked as skipped, while both real occurrences of a fall-back time are returned as ambiguous. detect_dst_risk looks one year ahead and reports each date where the schedule meets a DST transition.
Setup and configuration
The hosted option is available through MCPize, which the project identifies as its recommended deployment path. The README lists a free tier and a $7/month Pro plan for that hosted service.
For self-hosting, install the Node.js dependencies from the repository and start the server:
npm install
node server.js
The provided setup instructions do not specify environment variables or additional configuration files.
Tools and capabilities
validate_cron_expression: Checks syntax and semantics, explains the schedule, and reports common cron footguns.
get_next_fire_times: Computes upcoming fire times with DST-aware skipped and duplicated-time indicators.
detect_dst_risk: Scans the next year for dates affected by DST transitions.
Run detect_dst_risk once for jobs scheduled in the local 1–4am window before shipping them. Use get_next_fire_times when you need to inspect concrete upcoming executions, including behavior around a transition date.
Limitations and notes
Results depend on the platform's timezone data and the timezone associated with the schedule being evaluated. DST analysis is specifically concerned with local times that collide with spring-forward gaps or fall-back overlaps; it is not a general job-delivery monitor. The README recommends a yearly risk scan for schedules in the 1–4am window, while validation separately nudges users to check schedules in the 1–3am range.
The project does not describe logging, job execution, notification delivery, or changes to an existing scheduler. It audits expressions and calculated fire times rather than running cron jobs. Its license is MIT.