Pick a preset or type an expression. See the next five run times and a plain-English explanation before you ship it.
Pick a preset or type a 5-field cron expression. Next run times are computed in your browser, in your timezone.
A generic cron builder assumes you already know what field order means. A scheduled SQL job usually starts from a plain-English requirement instead: "run this every weekday morning before the team gets in" or "run this every four hours." This tool works in both directions: pick a preset and it fills in the cron string, or type a cron string and it explains what it does in plain English, including the next five times it would actually fire.
Take 52 8 * * 1-5, a common shape for "run before the workday starts." Reading left to right: minute 52, hour 8, day-of-month * (any), month * (any), day-of-week 1-5 (Monday through Friday). That reads as 8:52 AM, Monday through Friday, every month. The minute is deliberately not :00 or :30; landing a job a few minutes off the hour avoids the pile-up of everyone else's jobs that also fire exactly on the hour.
minute hour day-of-month month day-of-week 52 8 * * 1-5 -> weekdays at 8:52 AM
Standard cron has one genuinely confusing rule: when both day-of-month and day-of-week are restricted (neither is *), a date matches if either condition is true, not both. 0 0 1 * 1 doesn't mean "the first of the month, if it's a Monday." It means "midnight on the 1st, OR any Monday," which fires far more often than most people expect. If you only mean "the 1st, and only if it's a Monday," you need application logic outside cron to check that, since cron's own semantics can't express an AND between those two fields. This tool's next-run preview makes that trap visible immediately instead of after the first surprise run.
0 */4 * * * reads as minute 0, every 4th hour, any day, any month, any weekday: midnight, 4 AM, 8 AM, noon, 4 PM, 8 PM. If a job needs to avoid the very top of the hour, shift the minute field instead of the hour step: 10 */4 * * * keeps the same four-hour cadence but lands at :10 each time.
QueryFlow's job scheduler doesn't require you to write cron by hand for common cases. Its Schedule options are Manual, Interval, Daily, Weekly, and Custom Cron. Interval, Daily, and Weekly cover most of what the presets above express through a picker instead of a text field; Custom Cron accepts exactly the 5-field syntax this tool builds, for anything more specific than the built-in presets cover, like "weekdays at 8:52" or "first business day of the month." Background jobs against Snowflake, Redshift, BigQuery, and Databricks run through QueryFlow's background helper even with the app closed; jobs against other connectors run while QueryFlow is open.
No. The cron parser and next-run calculation both run in your browser in JavaScript. Nothing is submitted to a server.
Standard cron treats them as an OR, not an AND, whenever both are restricted. "1st of the month AND Monday" isn't expressible in plain cron; you'd need application logic for that exact combination.
Whatever timezone your browser is set to. The calculation uses your local clock, not UTC, unless your system clock is set to UTC.
No. Its scheduler has Manual, Interval, Daily, and Weekly pickers for common cases, plus Custom Cron for anything more specific, using the same 5-field syntax this tool builds.
No. Standard cron's smallest unit is one minute; sub-minute scheduling isn't part of the 5-field format this tool works with.
QueryFlow schedules SQL jobs against nine connectors, with Custom Cron built in.
No credit card. 14 days. Cancel in one click.