mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
On the maintenance creation form, link start and end times together #4752
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#4752
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 @tayflo on GitHub (Feb 24, 2026).
📑 I have found these related issues/pull requests
This issue follows a discussion here: https://github.com/louislam/uptime-kuma/issues/7042#issuecomment-3955096031
🔖 Feature description
Right now, upon new maintenance creation, start datetime and end datetime are not linked whatsoever: it's even possible to set a end time which predates the start time without raising any error.
All of this could be slightly smarter.
✔️ Solution
I see this issue in three parts:
The end datetime could be modified dynamically upon modification of start datetime:
When start date is changed manually, use the currently selected duration to re-compute the end date accordingly. For instance:
The only exception to that should be when the user has already modified the end date manually. In that case, just select the matching duration, if applicable.
Changing end date or duration should keep the same behavior as the current one:
When end date is changed manually, select the matching duration if applicable (start date does not change)
When duration is changed manually, re-compute the end date accordingly (start date does not change)
Regarding coherence between start and end: if end date predates start date, I would say:
Because, maybe the user want to first change the end date, and intended to change the start date just right after that (in that case, rejecting the input would feel unpleasant).
❓ Alternatives
N/A
📝 Additional Context
N/A
@prakash-218 commented on GitHub (Feb 26, 2026):
Can I pick this up?
@CommanderStorm commented on GitHub (Feb 26, 2026):
sure