Compute next cron run times from any schedule
See exactly when a cron schedule will fire next, in UTC: 30 9 * * 1-5 counted from noon on 24 July 2026 gives 9:30 on 27, 28, 29 and 30 July, since Friday's run has already passed. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Cron expression
- 30 9 * * 1-5
- Start timestamp
- 2026-07-24T12:00:00Z
- Quantity
- 4
- Next runs
- 2026-07-27T09:30:00Z, 2026-07-28T09:30:00Z, 2026-07-29T09:30:00Z, 2026-07-30T09:30:00Z
Turn a five-field Unix cron expression into a concrete, ordered list of future execution times. Provide the schedule, an ISO 8601 starting timestamp, and the number of occurrences you need. The calculator validates malformed expressions instead of guessing, applies familiar cron rules for ranges, lists, and steps, and returns normalized UTC timestamps that are easy to review, test, store, or compare before a scheduled job is deployed. The calculation is fully deterministic.
Preview a cron schedule with a fixed starting point
A cron expression is compact, but compact syntax is easy to misread during a deployment review. This calculator replaces interpretation by inspection with a specific sequence of timestamps. Enter the five fields in the traditional order: minute, hour, day of month, month, and day of week.
Then provide an ISO 8601 starting timestamp with either Z or an explicit numeric offset. You can request between one and fifty occurrences. No current clock is consulted, so rerunning an old validation remains reproducible.
Understand the supported five-field cron rules
Each field accepts an asterisk, an individual number, a comma-separated list, an inclusive range, or a step. Expressions such as */15, 1-5, 0,30, and 2-10/2 therefore work without special options. Minutes range from 0 through 59, hours from 0 through 23, days of month from 1 through 31, months from 1 through 12, and days of week from 0 through 7, where both 0 and 7 mean Sunday.
This capability uses the common Unix relationship between the two day fields: when both day of month and day of week are restricted, a date matches when either restriction matches. When one of those fields is an asterisk, the other field controls the date. The syntax deliberately excludes seconds, year fields, names such as MON, and vendor extensions such as L, W, ?, or #.
Rejecting unsupported forms is safer than silently assigning them a meaning that differs from the scheduler where the expression will eventually run.
Use the results in reviews, tests, and operations
Schedule previews are valuable anywhere a cron string crosses a human or system boundary. In a configuration interface, show the next several UTC occurrences before the user saves a job. During incident analysis, start immediately before the relevant period and establish whether the configured expression could have produced the observed executions.
The calculation is deterministic and local: it uses no network service, stored state, random value, or machine timezone. Invalid field counts, out-of-range numbers, descending ranges, zero steps, impossible timestamps, and unsupported tokens produce an invalid-input error with a useful message. Because timestamps are returned in canonical UTC form, downstream code can compare them directly without first reconciling locale-specific display formats.
What you can do with it
Check a deployment schedule
List the next runs during code review and catch an incorrect field, range, or frequency before the scheduled job is enabled.
Build a schedule preview
Show concrete UTC execution times beside a cron editor so users can confirm what their configuration will do.
FAQ
Which cron format is supported?
The calculator accepts traditional five-field Unix cron expressions in minute, hour, day-of-month, month, and day-of-week order.
Are the returned times inclusive of the starting timestamp?
No. Every result is strictly later than the supplied starting instant, even when that instant falls exactly on a scheduled minute.
Which timezone is used?
The numeric offset in the starting timestamp is honored, and all calculated run times are returned in UTC with a Z suffix. The cron fields themselves are evaluated in UTC.
What happens when the cron expression is malformed?
The calculator never repairs or guesses an expression.
What happens when both the day of month and the day of week are set?
A date matches when either one matches, following the usual Unix rule. If one of the two is an asterisk, the other alone decides which dates count.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/web/cron-next-runs \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"cron_expression":"30 9 * * 1-5","start_timestamp":"2026-07-24T12:00:00Z"}'const res = await fetch("https://api.kit.forhosting.com/web/cron-next-runs", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"cron_expression": "30 9 * * 1-5",
"start_timestamp": "2026-07-24T12:00:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/cron-next-runs",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"cron_expression": "30 9 * * 1-5",
"start_timestamp": "2026-07-24T12:00:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/cron-next-runs", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"cron_expression":"30 9 * * 1-5","start_timestamp":"2026-07-24T12:00:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"cron_expression":"30 9 * * 1-5","start_timestamp":"2026-07-24T12:00:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/cron-next-runs", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"cron_expression": "30 9 * * 1-5",
"start_timestamp": "2026-07-24T12:00:00Z"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.cron_next_runs",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_items | 50 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Use the results in reviews, tests, and operations
The API price is $0.002 per request, while the browser tool can perform the same calculation locally.
Integration use cases
Create deterministic test fixtures
Generate expected occurrences from a fixed starting timestamp and compare them in automated tests without consulting the current clock.
Technical questions
How much does an API request cost?
Each API request costs $0.002. The equivalent calculation is also available locally in the browser.