ForHosting KIT · Web Scraping & Monitoring

Compute next cron run times from any schedule

Turn a five-field Unix cron expression into a concrete, ordered list of future execution times.

● BetaFree · in your browser

Use it from WebAPIEmailTelegramApp soon

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. Every returned occurrence is strictly later than that instant and is normalized to UTC, so the same request produces the same result in a browser, test runner, or server. This explicit starting point matters when a schedule is being tested around midnight, month boundaries, leap years, or an offset transition. You can request between one and fifty occurrences. The response contains only the ordered run times, which makes it suitable for a preview, a fixture, or a direct equality check in an automated release gate. 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. In continuous integration, compare the generated sequence with an approved fixture so a frequency change cannot hide inside a small text edit. 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. The API price is $0.002 per request, while the browser tool can perform the same calculation locally. 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.

Create deterministic test fixtures

Generate expected occurrences from a fixed starting timestamp and compare them in automated tests without consulting the current clock.

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 request fails with an invalid-input error describing the malformed field or unsupported value. The calculator never repairs or guesses an expression.

How much does an API request cost?

Each API request costs $0.002. The equivalent calculation is also available locally in the browser.

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

POSThttps://api.kit.forhosting.com/web/cron-next-runs

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

Per request$0.002

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.

Read the full KIT documentation →