Cron expression generator
Every 5 minutes
Presets
Next run times
Run times load in your browser, in your timezone.
Just calling a URL on a schedule? Omniyond calls any HTTPS endpoint on a repeating interval, from every 5 minutes to every 90 days. For example, */5 * * * * becomes every 5m. It retries failures and emails you if a call still fails. It runs intervals, not full cron expressions.
Schedule an HTTP call every N minutes →How cron expressions work
A standard cron expression has five fields separated by spaces. Each field narrows down when the job runs, and the job fires at every minute where all of them match.
| Field | Allowed values | Example |
|---|---|---|
| Minute | 0-59 | 30 runs at half past the hour |
| Hour | 0-23 | 9 runs in the 09:00 hour |
| Day of month | 1-31 | 1 runs on the 1st |
| Month | 1-12 or JAN-DEC | */3 runs every third month |
| Day of week | 0-7 or SUN-SAT (0 and 7 are Sunday) | 1-5 runs Monday to Friday |
Four special characters do most of the work:
*matches every value.,lists values:0,30in the minute field means on the hour and at half past.-sets a range:9-17in the hour field covers 09:00 to 17:59./sets a step:*/15in the minute field means every 15 minutes, and10-50/20means minutes 10, 30 and 50.
Some tools add a sixth field for seconds at the front, and Quartz-style schedulers add ?, L, W and #. Standard Linux cron doesn't understand those, so the generator flags them.
Common cron expressions
These cover most real schedules. Click any preset in the tool to load it.
| Expression | Runs |
|---|---|
* * * * * | Every minute of every day |
*/5 * * * * | At minute 0, 5, 10 and so on, all day |
*/15 * * * * | At minute 0, 15, 30 and 45 of every hour |
0 * * * * | At the start of every hour |
0 0 * * * | At 00:00 every day |
0 9 * * 1-5 | At 09:00, Monday to Friday |
0 0 * * 1 | At 00:00 every Monday |
0 0 1 * * | At 00:00 on the 1st of every month |
How to read your cron expression generator results
The plain English line tells you what the expression means. The list next to it is the proof: the next 5, 10 or 25 times it fires, counted from right now.
Each run shows two clocks. The first is the timezone you picked, which starts as your browser's. The second is UTC, because that's what most servers, containers and hosted platforms run on. If you write 0 9 * * * on a server set to UTC and you live in New York, the job runs at 05:00 your time in summer and 04:00 in winter, not at 09:00.
To use it as a cron time converter, set the selector to the zone your cron daemon runs in. The list then shows when the job really fires, in that zone and in UTC. The link you copy keeps both the expression and the timezone, so a teammate sees the same schedule.
When a run lands on a daylight saving change, the tool adds a note. In spring an hour of local time is skipped, so a job set inside it may not run that day or may run late, depending on the daemon. In autumn an hour repeats, so a job inside it may run once or twice. Scheduling in UTC avoids both.
Cron gotchas
Day of month OR day of week. If you restrict both day fields, standard cron runs when either one matches, not both. 0 9 13 * 5 runs on every 13th and on every Friday, not only on Friday the 13th. Leave one of them as * unless you mean OR.
Server timezone vs yours. Cron uses the timezone of the machine it runs on, and platform crons usually run in UTC. Cloudflare Cron Triggers, for example, are always UTC. See Cloudflare cron triggers vs a hosted scheduler for where those limits bite.
Overlapping runs. Cron starts the next run on time even if the last one is still going. A job that runs every minute and sometimes takes 90 seconds ends up with two copies running at once. Use a lock (flock on Linux) or make the job safe to run twice.
Silent failures. Cron doesn't tell you when a job fails. Output goes to local mail or nowhere, and a job that stopped running looks the same as one with nothing to do. Log the exit code somewhere you read, or use a monitor that alerts when a run is missed.
Running a cron schedule without a server
A lot of scheduled jobs are a single HTTP request: hit an endpoint to send a digest, sync a feed or clear a cache. Keeping a server alive just to run crontab for that is a lot of upkeep. Platform crons on Vercel, Supabase or Cloudflare help, but each has its own limits on how many schedules you get, how often they fire and which timezone they use, and they're set when you deploy rather than created by your app.
Omniyond is a hosted HTTP scheduler. You give it a URL and how often to call it, from every 5 minutes up to every 90 days, and it makes the call on that repeat. Schedules are intervals rather than full cron expressions: */5 * * * * becomes 5m and 0 * * * * becomes 1h, but "weekdays at 09:00" has no interval form. Intervals count from when you create the job, not from the top of the hour.
If a call errors or the URL returns a 5xx or 429, Omniyond retries it after 30 seconds, then 5 minutes, then 30 minutes. If all of those fail, it stops the job and emails you. Once the endpoint is fixed, you restart the job from the dashboard or the API.
For heavier workflows, compare Omniyond vs Inngest for scheduled jobs, read about a lighter alternative to Temporal for simple schedules, or browse other job schedulers.