Home › Catalog › Cron Tool › Why Forge Cron
Crontab.guru is the right tool when you want to type */15 9-17 * * 1-5 and read back "at every 15th minute past every hour from 9 through 17 on every day of the week from Monday through Friday." It is also strictly a browser tool with no public API. The Forge Cron API is what you reach for when you need to validate cron expressions in code, predict the next ten runs in Asia/Tokyo, or test whether an expression fires at a specific instant.
| Feature | Forge Cron | Crontab.guru |
|---|---|---|
| Parse + describe in plain English | ✓ (GET /cron/parse) | ✓ (browser) |
| Free REST API for scripts & CI | ✓ | × |
| Next N runs in any IANA timezone | ✓ (GET /cron/next?tz=Asia/Tokyo) | ✓ (limited; no timezone selector) |
| Previous N runs | ✓ (GET /cron/prev) | × |
| Match-at-instant test (does it fire at time X?) | ✓ (GET /cron/match) | × |
| Structured builder (build expression from a form) | ✓ (POST /cron/builder) | × |
| Library of common patterns | ✓ (GET /cron/common, 24 patterns) | partial (examples page) |
Alias expansion (@hourly, @daily, …) | ✓ | partial |
| Cost | $0, no signup, no API key | $0, browser only |
This is the load-bearing difference. Crontab.guru renders a plain-English description in a browser tab. It does not return JSON. There is no documented endpoint you can hit from a deploy script that validates a cron string before it lands in production. Forge Cron is the inverse:
curl "https://forge-node.tail2b516d.ts.net/cron/parse?expr=*/15+9-17+*+*+1-5"
Response is a structured JSON object with the description, the per-field breakdown, and a validation flag. Drop that call into your CI to fail the build if someone commits a bad cron string.
The most common "why is this job firing at the wrong time?" bug is a timezone mismatch. GET /cron/next?expr=...&tz=Europe/Berlin&count=10 returns the next ten run times in the timezone you specify, with both the local ISO timestamp and the UTC equivalent. No more crontab-guru-plus-mental-arithmetic.
curl "https://forge-node.tail2b516d.ts.net/cron/next?expr=0+9+*+*+*&tz=America/Los_Angeles&count=5"
One of the most useful tools for a scheduler bug is "given this expression and this exact timestamp, would the job have fired?" GET /cron/match?expr=...&at=2026-05-19T03:30:00-07:00 returns a boolean plus the surrounding context (previous matching instant, next matching instant). This is the endpoint your "why didn't the report run last night?" debugger calls.
Letting users type raw cron expressions is a UX failure waiting to happen. POST /cron/builder takes a structured payload (frequency type, hour, minute, day-of-week list) and returns the equivalent cron expression plus its plain-English description. Wire that into an admin UI and your users build the schedule with dropdowns; they never see a star.
GET /cron/common returns 24 vetted common patterns (every 15 minutes, weekday mornings at 9, last Friday of the month, …) categorized by frequency. Use it to seed an autocomplete in your scheduler UI or to remind your future self what "every Tuesday at 4 PM" actually looks like.
schedule.yaml fails /cron/parse./cron/builder, store the canonical expression./cron/next?tz=... with the user's timezone to show them when their report will actually run./cron/prev on each expected schedule, compare against actual job logs, alert on misses./cron/parse next to every cron field in your config docs.Yes. No signup, no API key. Rate-limited per IP to keep abuse low; details in the Cron API docs.
Standard 5-field crontab plus the well-known aliases (@hourly, @daily, @midnight, @weekly, @monthly, @yearly, @annually). @reboot is intentionally excluded because it is a daemon directive, not a schedule.
Any IANA Time Zone Database name (America/Los_Angeles, Europe/Berlin, Asia/Tokyo, …). The full list is whatever your platform's zoneinfo ships.
Try the Cron tool, or browse the full free API catalog for 15 more developer APIs.