Disclaimer

Best-effort humanisation and scheduling

The plain-English description the Service produces for a given expression is generated by an opinionated humaniser. The next ten execution times are computed by a deterministic scheduler that walks the expression's constraints forward from a reference instant. Both pieces of code are covered by automated tests against a corpus of expressions, but neither is a formal model of every cron daemon ever shipped. Production systems should validate critical expressions independently — for example, by dry-running the daemon on a test host, or by hitting the /next endpoint from a CI job and asserting against the result.

Day-of-month / day-of-week is OR, not AND

The single largest source of incorrect cron expressions on the internet is the assumption that setting both the day-of-month and day-of-week fields means “both must match”. In standard Unix cron the two fields are joined with logical OR when both are restricted from *. So 0 0 1 * 1 fires at midnight on the first of every month and at midnight every Monday — usually four to five times the cadence the author intended.

AWS EventBridge intentionally breaks with the Unix convention and requires exactly one of the two fields to be ? instead of *; Quartz follows the same convention. The Service's humaniser flags the OR-semantics case where it can, but cannot always tell whether you meant AND or OR — when in doubt, build the expression visually rather than typing it.

Daylight Saving Time can double-fire or skip

When the host running cron is configured to a timezone that observes Daylight Saving Time, jobs scheduled inside the transition window behave inconsistently. The default Unix cron behaviour is to skip a job that would have fired during the lost hour in spring (when the clock jumps from 2:00 to 3:00), and to fire a job twice during the duplicated hour in autumn (when the clock falls from 2:00 back to 1:00). The Service displays next-execution times in UTC by default, and in whichever IANA timezone you select, but it does not simulate every cron daemon's DST behaviour. If your job must not double-fire on a DST transition night, the safest pattern is to run the underlying daemon in UTC and to make the job itself idempotent.

Step values that do not divide the range

A step like */7 in the minute field does not produce a perfectly even 7-minute cadence. The cron scheduler resets the step at the top of every hour, so the gap between the last fire of one hour (minute 56) and the first fire of the next (minute 0) is only four minutes. The Service shows this clearly in the calendar preview, but the textual humanisation may say “every 7 minutes” without that caveat. Prefer step values that divide the field range evenly: */5, */10, */15, */20, or */30.

Platform minimum intervals

Some platforms cap how often a scheduled task can run. GitHub Actions enforces a five-minute minimum interval and may further delay scheduled runs during periods of high load. Vercel's Hobby plan enforces a daily minimum (with hourly available on paid tiers). AWS EventBridge supports per-minute schedules but bills per invocation, so a one-minute schedule has cost implications. The Service accepts and humanises any valid expression but will not warn you that your platform refuses to honour it.

No professional advice

The Service is not legal, financial, security, or operational advice. The platform setup guides describe what the relevant vendor documentation says at the time of writing; they are not a substitute for that documentation, which is authoritative and may change without notice.

Affiliate content policy

At the time of writing the Service contains no affiliate links and earns no commission on any outbound link. The site is supported entirely by Google AdSense display advertising. If affiliate links are ever introduced — for example to a recommended monitoring tool or hosting provider — the relationship will be disclosed inline at the point of the link, in this Disclaimer, and on the About page.

Reporting an error

If the Service's humaniser or scheduler produces output that does not match what a real cron daemon does in your environment, please email tech@serviceproviderskenya.com with the expression, the format you were targeting, and the observed versus expected behaviour. These are the most useful bug reports the operator receives.