Maintenance Time Window of a Day do not consider DST #4365

Open
opened 2026-02-28 03:59:45 -05:00 by deekerman · 10 comments
Owner

Originally created by @mdima on GitHub (Oct 23, 2025).

Does not apply

🛡️ Security Policy

📝 Description

Hello,
I just realized why I continue to receive alerts of the selected monitors during the maintenance window: the Time Window of a Day setting in the maintenance plan do not consider the Day Light Saving status.

At the moment there is no alternative to solve the problem than setting a different Timezone to compensate the DST, but would be better if this would be managed.

👟 Reproduction steps

Set a maintenance interval during the DST period, the selected monitors will not be excluded during that interval.

👀 Expected behavior

Just consider DST when applying the maintenance interval.

😓 Actual Behavior

The DST period is ignored, this means that the maintenance interval is shifted 1h later.

🐻 Uptime-Kuma Version

Version: 2.0.2

💻 Operating System and Arch

Docker

🌐 Browser

Google Chrome Version 141.0.7390.108 (Official Build) (64-bit)

🖥️ Deployment Environment

  • Runtime Environment:
    • Docker: Version 28.5.0, build 887030f
    • Docker Compose: Version v2.39.4
    • Portainer (CE): 2.33.0 LTS
  • Database:
    • SQLite: Embedded
  • Database Storage:
    • Filesystem:
      • Linux: ext4/XFS/Btrfs/ZFS/F2FS
      • macOS: APFS/ HFS+
      • Windows: NTFS/ReFS
    • Storage Medium: NVMe
  • Uptime Kuma Setup:
    • Number of monitors: `30

📝 Relevant log output


Originally created by @mdima on GitHub (Oct 23, 2025). ### 📑 I have found these related issues/pull requests Does not apply ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description Hello, I just realized why I continue to receive alerts of the selected monitors during the maintenance window: the Time Window of a Day setting in the maintenance plan do not consider the Day Light Saving status. At the moment there is no alternative to solve the problem than setting a different Timezone to compensate the DST, but would be better if this would be managed. ### 👟 Reproduction steps Set a maintenance interval during the DST period, the selected monitors will not be excluded during that interval. ### 👀 Expected behavior Just consider DST when applying the maintenance interval. ### 😓 Actual Behavior The DST period is ignored, this means that the maintenance interval is shifted 1h later. ### 🐻 Uptime-Kuma Version Version: 2.0.2 ### 💻 Operating System and Arch Docker ### 🌐 Browser Google Chrome Version 141.0.7390.108 (Official Build) (64-bit) ### 🖥️ Deployment Environment - **Runtime Environment**: - Docker: Version 28.5.0, build 887030f - Docker Compose: Version v2.39.4 - Portainer (CE): 2.33.0 LTS - **Database**: - SQLite: Embedded - **Database Storage**: - **Filesystem**: - Linux: ext4/XFS/Btrfs/ZFS/F2FS - macOS: APFS/ HFS+ - Windows: NTFS/ReFS - **Storage Medium**: NVMe - **Uptime Kuma Setup**: - Number of monitors: `30 ### 📝 Relevant log output ```bash session ```
Author
Owner

@maxmichels commented on GitHub (Oct 23, 2025):

I cannot reproduce. On my Status Page it is shown with the Timezone i specified for the Maintenance. Can you explain what exactly you mean?

@maxmichels commented on GitHub (Oct 23, 2025): I cannot reproduce. On my Status Page it is shown with the Timezone i specified for the Maintenance. Can you explain what exactly you mean?
Author
Owner

@mdima commented on GitHub (Oct 25, 2025):

Hello Max.
I set up a maintenance plan from 03:00AM to 03:15AM, but I receive the alerts as if the maintenance plan did not exist.
To solve the problem I changed the maintenance interval from 04:00AM to 04:15AM and I do not receive the alerts caused from the reboot of my wifi router anymore. My wifi router reboots every second day at 03:00AM.

The timezone is correct (Europe/Rome), so the only thing that could cause the issue is the presence of the DST (in Italy is from March 30 to October 26).

Do you have enough information to investigate the issue now?
Thank you!
Michele

@mdima commented on GitHub (Oct 25, 2025): Hello Max. I set up a maintenance plan from 03:00AM to 03:15AM, but I receive the alerts as if the maintenance plan did not exist. To solve the problem I changed the maintenance interval from 04:00AM to 04:15AM and I do not receive the alerts caused from the reboot of my wifi router anymore. My wifi router reboots every second day at 03:00AM. The timezone is correct (Europe/Rome), so the only thing that could cause the issue is the presence of the DST (in Italy is from March 30 to October 26). Do you have enough information to investigate the issue now? Thank you! Michele
Author
Owner

@acffordyce973 commented on GitHub (Oct 26, 2025):

Had the same issue today with the UK change. I had both the server and maintenance window set to Europe/London. Mine was for a device that is off during the night (from 11pm) and comes back on in the afternoon (2pm). I got an offline alert at 1pm even though the window was set for 2pm still.

@acffordyce973 commented on GitHub (Oct 26, 2025): Had the same issue today with the UK change. I had both the server and maintenance window set to Europe/London. Mine was for a device that is off during the night (from 11pm) and comes back on in the afternoon (2pm). I got an offline alert at 1pm even though the window was set for 2pm still.
Author
Owner

@louislam commented on GitHub (Oct 26, 2025):

Everyone are using 2.X?

Since I didn't see similar reports before, I guess it should be affected by this pr: https://github.com/louislam/uptime-kuma/pull/5914.

I think we need to set up some unit tests to test it.

@louislam commented on GitHub (Oct 26, 2025): Everyone are using 2.X? Since I didn't see similar reports before, I guess it should be affected by this pr: https://github.com/louislam/uptime-kuma/pull/5914. I think we need to set up some unit tests to test it.
Author
Owner

@acffordyce973 commented on GitHub (Oct 26, 2025):

I was on v1.23.16 but going to update to 2.x now.

@acffordyce973 commented on GitHub (Oct 26, 2025): I was on v1.23.16 but going to update to 2.x now.
Author
Owner

@mdima commented on GitHub (Oct 27, 2025):

Everyone are using 2.X?

Since I didn't see similar reports before, I guess it should be affected by this pr: #5914.

I think we need to set up some unit tests to test it.

Yes, version 2.0.2 actually.

@mdima commented on GitHub (Oct 27, 2025): > Everyone are using 2.X? > > Since I didn't see similar reports before, I guess it should be affected by this pr: [#5914](https://github.com/louislam/uptime-kuma/pull/5914). > > I think we need to set up some unit tests to test it. Yes, version 2.0.2 actually.
Author
Owner

@danielgoepp commented on GitHub (Jan 15, 2026):

I can confirm I can reproduce this too. I'm on Version: 2.1.0-beta.2.

I'm set to New_York:
Image

I just created a maintenance window and it shows UTC+00:00:
Image

@danielgoepp commented on GitHub (Jan 15, 2026): I can confirm I can reproduce this too. I'm on Version: 2.1.0-beta.2. I'm set to New_York: <img width="308" height="266" alt="Image" src="https://github.com/user-attachments/assets/e991bbda-7473-4a37-aca4-c39baabefc6e" /> I just created a maintenance window and it shows UTC+00:00: <img width="515" height="250" alt="Image" src="https://github.com/user-attachments/assets/4ab89aa8-7e5e-4639-ba15-a89750a96929" />
Author
Owner

@CommanderStorm commented on GitHub (Jan 15, 2026):

@danielgoepp when you edit the maintenance, what is the timezone? is it NYC as well?

@CommanderStorm commented on GitHub (Jan 15, 2026): @danielgoepp when you edit the maintenance, what is the timezone? is it NYC as well?
Author
Owner

@danielgoepp commented on GitHub (Jan 15, 2026):

@CommanderStorm my bad, I didn't even notice that! So, perhaps I should rephrase what I think is wrong here.

Image

It allows you to just leave this blank, and it doesn't pre-populate with a default value. So as you can seen, I had just left it blank, so it defaulted to UTC+00:00. If I set it to same as server, it works fine.

This appears to just be a user interface issue, not a functional issue.

I recommend requiring this field to be set and/or warn the user if they don't set it. I would also just default to "same as server" when the form loads, not blank. Making this an "override" field if necessary, but the default value would be same as server. 100% of the time I would want it to be same as server, and I wouldn't want to have to explicitly say that every time.

@danielgoepp commented on GitHub (Jan 15, 2026): @CommanderStorm my bad, I didn't even notice that! So, perhaps I should rephrase what I think is wrong here. <img width="820" height="334" alt="Image" src="https://github.com/user-attachments/assets/e1ec57d8-70b5-4511-ad8b-2b95ba2a8dce" /> It allows you to just leave this blank, and it doesn't pre-populate with a default value. So as you can seen, I had just left it blank, so it defaulted to UTC+00:00. If I set it to same as server, it works fine. This appears to just be a user interface issue, not a functional issue. I recommend requiring this field to be set and/or warn the user if they don't set it. I would also just default to "same as server" when the form loads, not blank. Making this an "override" field if necessary, but the default value would be same as server. 100% of the time I would want it to be same as server, and I wouldn't want to have to explicitly say that every time.
Author
Owner

@CommanderStorm commented on GitHub (Jan 15, 2026):

If you update your instance to our latest nightly, papercuts in this area were fixed yesterday:

@CommanderStorm commented on GitHub (Jan 15, 2026): If you update your instance to our latest nightly, papercuts in this area were fixed yesterday: - https://github.com/louislam/uptime-kuma/pull/6718
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uptime-kuma#4365
No description provided.