Azure Automation schedules shifted by one hour after DST change and Portal displays incorrect Start time

We are experiencing what appears to be a DST-related issue with Azure Automation schedules following the transition from Mountain Daylight Time to Mountain Standard Time in Alberta, Canada.

Issue 1: Existing schedules are executing one hour later

Following the DST transition, existing Azure Automation schedules began executing one hour later than they were originally configured/intended to run.

This affected multiple schedules. We initially had schedules configured using a Mountain timezone, but after the time change their Next run times shifted by one hour and the jobs actually executed at those later times.

To work around the issue, we have had to reschedule affected jobs using UTC rather than Mountain time.

The issue does not appear limited to a particular browser or workstation. We have reproduced the behavior across multiple browsers and workstations.

Issue 2: Azure Portal displays the Start time incorrectly

While troubleshooting, we created a new schedule explicitly in UTC using Azure CLI.

az automation schedule create \

  --resource-group "foo-rg" \

  --automation-account-name "foo-automation-account" \

  --name "Test-1345-UTC" \

  --start-time "2026-11-07T13:45:00+00:00" \

  --frequency Day \

  --interval 1 \

  --time-zone "Etc/UTC"

When retrieving the schedule through Azure CLI the relevant values are correct:

"nextRun": "2026-11-07T13:45:00+00:00",

"nextRunOffsetMinutes": 0.0,

"startTime": "2026-11-07T13:45:00+00:00",

"startTimeOffsetMinutes": 0.0,

"timeZone": "Etc/UTC"

The job also executes at the correct nextRun time.

However, the Azure Portal displays the same schedule as:

Starts: 12:45 PM

Next run: 1:45 PM

Therefore, for this schedule:

• Source: Azure CLI
• Start: 13:45 UTC
• Next Run: 13:45 UTC
• Source: Azure Portal
• Start: 12:45 PM
• Next Run: 1:45 PM

Actual execution: 13:45 UTC

The stored startTime is therefore correct, and actual execution follows the reported nextRun, but the Starts value displayed by the Azure Portal is one hour behind.

What we have confirmed

1. The problem became apparent in conjunction with the DST change in Alberta.
2. Existing schedules began executing one hour later than intended.
3. The jobs actually execute at the displayed/calculated Next run time, so this is not solely a cosmetic Portal issue for the existing schedules.
4. Moving/reconfiguring affected schedules to UTC has allowed us to restore the desired execution times.
5. A newly created UTC schedule has the correct startTime and nextRun through Azure CLI.
6. For the UTC test schedule, the Portal displays Starts one hour earlier than the value returned by Azure CLI/API.
7. The Portal behavior reproduces across multiple browsers and workstations.
8. Changing the timezone selected on the schedule does not appear to resolve the inconsistent Start-time presentation.

Expected Behaviour

For schedules configured with a DST-aware Mountain timezone, we expect Azure Automation to preserve the configured local execution time across the DST transition.

For a UTC schedule configured as:

• Start: 2026-11-07 13:45 UTC
• Timezone: Etc/UTC

we expect the Azure Portal to display the same 13:45 UTC start time returned by the Azure Automation API/CLI.

Questions

1. Is there a known Azure Automation scheduling issue associated with the November 2026 DST transition?
2. Why would existing DST-aware schedules shift their actual Next run and execution time by one hour following the DST transition?
3. Is there a known Azure Portal issue causing the Starts field to be rendered one hour differently from the underlying startTime returned by Azure CLI/API?
4. Is using UTC for these schedules the recommended workaround?
5. If this is a known service or Portal defect, is there a tracking ID or expected remediation?

At this point we are using UTC schedules as a workaround, but would like to determine whether this is a known Azure Automation/DST issue and whether existing schedules need to be recreated or can eventually be returned to a Mountain timezone.