Use Case / Problem
Use Case / Problem
What I'm trying to accomplish
I want to schedule Fabric items (notebooks and Data Pipelines) on a recurring pattern that combines three things at once: a sub-hourly interval, a time-of-day window, and a day-of-week filter. Concretely: run every 15 minutes, between 06:00 and 19:00, Monday through Friday. In standard crontab that's a single expression:
Current limitation
Finding --type cron in the CLI docs (Create Cron-based Schedule) looked like exactly what I needed. It isn't — "Cron" here means "a fixed interval in minutes," not a cron expression. From src/fabric_cli/utils/fab_cmd_job_utils.py, in _process_schedule_args:
case "Cron":
if not re.match(r"^\d+$", args.interval):
raise FabricCLIError(
f"Invalid format for interval: {args.interval}. Must be an integer.",
fab_constant.ERROR_NOT_RUNNABLE,
)
schedule["interval"] = int(args.interval)--interval must be a bare integer, so */15 6-19 * * 1-5 is rejected outright. The three available types are:
cron → fixed interval in minutes, runs continuously with no window or day constraintsdaily → an explicit list of HH:mm timesweekly → an explicit list of times plus a list of weekdays
None of them can express "every N minutes, within a window, on selected days."
Pain points
- The name sets the wrong expectation.
--type cron and a docs section headed "Create Cron-based Schedule" both strongly imply crontab semantics. I spent real time assuming I'd made a syntax error before reading the source.
- The only workaround that actually works is horrible. To get
*/15 6-19 * * 1-5 today, I have to enumerate every single time slot: --type weekly --interval 06:00,06:15,06:30,...,19:00 --days Monday,Tuesday,Wednesday,Thursday,Friday — 53 comma-separated values in one flag. It's unreadable, error-prone to edit, painful to diff in a PR, and I have no idea whether it will hit an undocumented limit on list length.
- The alternatives are worse. Either create multiple schedules with narrow start/end windows, or move scheduling out of Fabric entirely into Logic Apps / Power Automate / GitHub Actions calling the Run On Demand endpoint — which defeats the point of native scheduling.
- Related: timezone is hardcoded. When using the flag-based form, the CLI always sets
schedule["localTimeZoneId"] = "UTC". A "06:00–19:00 business hours" window is inherently local-time, so DST shifts it twice a year. Getting a real timezone requires dropping down to raw JSON via --input.
How this fits my workflow
I manage Fabric schedules as code: fab commands live in deployment pipelines so that schedules are versioned, reviewed, and promoted across dev/test/prod alongside the items themselves. A cron string is the natural fit for that — it's one reviewable line, it's portable, and every engineer on the team already reads it fluently. Generating and maintaining 53-element time arrays per environment is exactly the kind of thing IaC is supposed to eliminate.
Proposed Solution
What I'm asking for
Support a genuine crontab expression, e.g. fab job run-sch <path> --type cron --expression "*/15 6-19 * * 1-5".
Related community idea: https://community.fabric.microsoft.com/idea/fbc_ideas/cron-based-schedules/5361080
Alternatives Considered
No response
Impact Assessment
Implementation Attestation
Implementation Notes
I recognise this is likely constrained by the platform: the Job Scheduler REST API defines Cron as { type, interval, startDateTime, endDateTime, localTimeZoneId } with an integer interval, and there's no field for an expression. So this may need to be carried upstream to the scheduler API team. Raising it here anyway because (a) the CLI is where the naming collision causes the confusion, and (b) the CLI is the automation surface where cron syntax matters most.
Use Case / Problem
Use Case / Problem
What I'm trying to accomplish
I want to schedule Fabric items (notebooks and Data Pipelines) on a recurring pattern that combines three things at once: a sub-hourly interval, a time-of-day window, and a day-of-week filter. Concretely: run every 15 minutes, between 06:00 and 19:00, Monday through Friday. In standard crontab that's a single expression:
Current limitation
Finding
--type cronin the CLI docs (Create Cron-based Schedule) looked like exactly what I needed. It isn't — "Cron" here means "a fixed interval in minutes," not a cron expression. Fromsrc/fabric_cli/utils/fab_cmd_job_utils.py, in_process_schedule_args:--intervalmust be a bare integer, so*/15 6-19 * * 1-5is rejected outright. The three available types are:cron→ fixed interval in minutes, runs continuously with no window or day constraintsdaily→ an explicit list ofHH:mmtimesweekly→ an explicit list of times plus a list of weekdaysNone of them can express "every N minutes, within a window, on selected days."
Pain points
--type cronand a docs section headed "Create Cron-based Schedule" both strongly imply crontab semantics. I spent real time assuming I'd made a syntax error before reading the source.*/15 6-19 * * 1-5today, I have to enumerate every single time slot:--type weekly --interval 06:00,06:15,06:30,...,19:00 --days Monday,Tuesday,Wednesday,Thursday,Friday— 53 comma-separated values in one flag. It's unreadable, error-prone to edit, painful to diff in a PR, and I have no idea whether it will hit an undocumented limit on list length.schedule["localTimeZoneId"] = "UTC". A "06:00–19:00 business hours" window is inherently local-time, so DST shifts it twice a year. Getting a real timezone requires dropping down to raw JSON via--input.How this fits my workflow
I manage Fabric schedules as code:
fabcommands live in deployment pipelines so that schedules are versioned, reviewed, and promoted across dev/test/prod alongside the items themselves. A cron string is the natural fit for that — it's one reviewable line, it's portable, and every engineer on the team already reads it fluently. Generating and maintaining 53-element time arrays per environment is exactly the kind of thing IaC is supposed to eliminate.Proposed Solution
What I'm asking for
Support a genuine crontab expression, e.g.
fab job run-sch <path> --type cron --expression "*/15 6-19 * * 1-5".Related community idea: https://community.fabric.microsoft.com/idea/fbc_ideas/cron-based-schedules/5361080
Alternatives Considered
No response
Impact Assessment
Implementation Attestation
Implementation Notes
I recognise this is likely constrained by the platform: the Job Scheduler REST API defines
Cronas{ type, interval, startDateTime, endDateTime, localTimeZoneId }with an integerinterval, and there's no field for an expression. So this may need to be carried upstream to the scheduler API team. Raising it here anyway because (a) the CLI is where the naming collision causes the confusion, and (b) the CLI is the automation surface where cron syntax matters most.