mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Maintenance Time Window of a Day do not consider DST #4365
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#4365
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mdima on GitHub (Oct 23, 2025).
📑 I have found these related issues/pull requests
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
📝 Relevant log output
@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?
@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
@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.
@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.
@acffordyce973 commented on GitHub (Oct 26, 2025):
I was on v1.23.16 but going to update to 2.x now.
@mdima commented on GitHub (Oct 27, 2025):
Yes, version 2.0.2 actually.
@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:

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

@CommanderStorm commented on GitHub (Jan 15, 2026):
@danielgoepp when you edit the maintenance, what is the timezone? is it NYC as well?
@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.
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.
@CommanderStorm commented on GitHub (Jan 15, 2026):
If you update your instance to our latest nightly, papercuts in this area were fixed yesterday: