microsoft / microsoft/fabric-cli

[FEATURE] CRONTAB based schedules

Open
#276 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ai:feature-triage:unable-to-process enhancement
Dominant language
Python
Stars
173
Forks
63
Avg merge
2d 19h
Merged PRs (30d)
4

Description

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:

*/15 6-19 * * 1-5

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 constraints
  • daily → an explicit list of HH:mm times
  • weekly → 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

  1. 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.
  2. 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.
  3. 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.
  4. 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
  • This would help me personally
  • This would help my team/organization
  • This would help the broader fabric-cli community
  • This aligns with Microsoft Fabric roadmap items
Implementation Attestation
  • I understand this feature should maintain backward compatibility with existing commands
  • I confirm this feature request does not introduce performance regressions for existing workflows
  • I acknowledge that new features must follow fabric-cli's established patterns and conventions
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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/fabric_cli/utils/fab_cmd_job_utils.py at _process_schedule_args, then review the Create Cron-based Schedule documentation and the linked Job Scheduler REST API definition. Determine whether the requested expression can be supported by the API or whether the actionable scope is clarifying the CLI's existing interval-based behavior; done should preserve backward compatibility and make the supported scheduling behavior unambiguous.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.