About SimpleCronTab

Editorial methodology

The visual builder, plain-English humaniser, next-execution preview, and format converter are powered by a custom cron engine written in TypeScript. The parser lives in lib/cron/parser.ts, the humaniser in lib/cron/humanizer.ts, and the next-execution scheduler in lib/cron/scheduler.ts. The same code that powers the on-page editor also powers the public JSON API at /api-docs — there is one source of truth for parsing and humanisation, not two.

Editorial pages — the cheat sheet, the tips, the format reference, the platform setup guides, and every per-schedule landing page — are written as TypeScript data files and reviewed by the operator before publication. Where an external syntax detail is borrowed (a 6-field Quartz quirk, a Vercel plan limit, a GitHub Actions minimum interval), the source is the relevant vendor's own published documentation, not a secondary blog post. Major sources used:

• The Unix crontab(5) and crontab(1) man pages for the canonical 5-field format.
• The Quartz Scheduler reference manual for the 6/7-field Java variant.
• AWS EventBridge / EventBridge Scheduler documentation for the 6-field AWS variant with year and the day-of-month / day-of-week mutual-exclusion requirement.
• Vercel's Cron Jobs documentation for plan-tier minimum intervals.
• GitHub Actions on.schedule documentation for the five-minute minimum and the “cron may be delayed” SLO.
• The Spring Framework cron documentation for the Spring 6-field format with seconds.

What makes this tool different

There are many cron parsers on the web. The most-cited is crontab.guru — a simple, fast, and authoritative reference. SimpleCronTab differs in a few specific ways:

• Click to build. Most cron tools accept an expression and explain it back to you. The visual builder works in the other direction: pick a cadence by clicking minute, hour, day, and day-of-week selectors, and the expression is generated as you go. Useful when you do not yet know the syntax.
• Next-execution preview as a calendar or timeline. Seeing the next ten fires on a real calendar makes off-by-one errors obvious — “every weekday at 9” looks correct as a string and obviously wrong as a row of Saturday markers.
• Compare mode. Two or three expressions side-by-side, diffing their next fires, for when you are migrating from one cadence to another and want to confirm there is no overlap or gap.
• Format converter. Translate between the standard 5-field Unix syntax, Quartz (6/7 fields with seconds and optional year), AWS EventBridge, Vercel, and GitHub Actions dialects.
• Free public API. The same parser is exposed as a JSON API at /api-docs — parse, validate, humanise, compute next executions, and convert between formats. Rate-limited but unauthenticated, so it is suitable for monitoring and CI checks without managing keys.

Reporting incorrect output

The humaniser is opinionated — it tries to produce English a human would actually say rather than a mechanical word-for-word translation. That means there are edge cases where it can be wrong. The best-known is the day-of-month / day-of-week OR-semantics gotcha: 0 0 1 * 1 fires on the first of every month and every Monday, not on the first of the month only when it is a Monday. The Disclaimer page covers a few more.

If you find a case where the humaniser says one thing and a production cron daemon does another, please email tech@serviceproviderskenya.com with the expression, the expected fire times, and (if you have them) the observed times. Reports are treated as bugs and tracked publicly in the repository.

Business model

The Service is free and is supported by Google AdSense advertising. There is no paid tier, no tracking pixel sold to another company, and no plan to introduce one. If the advertising model ever changes — for example by offering an ad-free option in exchange for a small subscription — that change will be announced on this page and on the home page before it goes live.