Hi @yatharth,

In Databricks Jobs, the scheduled trigger has two modes. Simple (also called periodic/interval) runs "Every N hours/days/weeks", whereas Advanced (cron) runs based on an explicit cron expression and timezone.

In the Simple/Periodic mode, Databricks explicitly does not let you specify the exact time of the first run. The first run time is chosen automatically when you configure the schedule. This is documented here.

After that first run, the job will run every N units from that chosen first-run time, not from the start time you picked in the UI and not from the current time.

When you create a periodic schedule (e.g., "Every 8 weeks"), and then later edit it to "Every 7 weeks", "Every 5 weeks", then back to "Every 8 weeks", each edit effectively creates a new periodic schedule. Each time, the scheduler recomputes the first run time based on when you saved that change, not based on your original start time field. That recalculated first run can land later the same day (e.g., "Next run at 11:54 AM today"), or land on a different calendar date than you expected when you go back to 8 weeks. That’s why the "Next run" appears earlier on the same day when you change 8 --> 7 weeks. When you go back to 8 weeks, "Next run" no longer matches the previous 8‑week date. You’ve effectively asked the system to pick a new first run for a new 8‑week schedule.

The start time field in the periodic UI is probably a bit misleading. It shows the effective first run in your timezone, but it is not treated as an immutable base anchor from which future runs are always recomputed. It’s a display of what the scheduler has chosen, not a fixed input that’s preserved when you edit the interval.

From your perspective (as a user), your expectation is very reasonable. You are basically saying... keep my base time fixed and change the interval. Don’t move the schedule around. However, based on the public scheduling doc above, the current behaviour is working as designed for Simple/periodic schedules. Simple schedules guarantee the interval. They do not guarantee that the first run or subsequent "Next run" values... as in stay anchored to a user‑chosen base timestamp when you change the interval.

The confusing part is mostly the UI wording and the fact that "Next run" is recomputed each time you edit, which makes it look unstable.

If you need stable, anchored timing (e.g., "exactly every 5/7/8 weeks from this base date at 10:15 IST"), there isn’t a built‑in trigger type that does that out‑of‑the‑box as of today. As a workaround, you can use advanced (cron) + a small guard in your code or accept periodic semantics and avoid edits.  This would mean using the Advanced schedule (cron) to run the job at a fixed local time (e.g., every day at 10:15 IST, or every week on a specific weekday/time). In your first task, add simple logic to read the timestamp of the last successful run (from a Delta table, a config table, or the job parameter store) and proceed only if ≥ N weeks have elapsed. Otherwise, exit quickly. This gives you a stable, predictable time-of-day and timezone (handled by cron) and true "every N weeks from this base" semantics controlled by your guard logic.

Your underlying ask... "let interval schedules honour a fixed base date/time, and keep 'Next run' anchored when changing the interval" is very reasonable UX feedback. Internally, this is treated as a feature request/enhancement rather than a scheduler bug, because the current behaviour matches the documented contract for Simple schedules ("scheduler chooses a time when you configure the schedule"). I’ll make sure this scenario and your IST example are passed along so PM/engineering can factor it into future improvements to Jobs scheduling UX.

In the meantime, for production‑critical workflows where an anchored schedule really matters, I’d recommend using Advanced (cron) + guard logic as above rather than relying on the periodic UI.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.