On the maintenance creation form, link start and end times together #4752

Open
opened 2026-02-28 04:13:59 -05:00 by deekerman · 2 comments
Owner

Originally created by @tayflo on GitHub (Feb 24, 2026).

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:

  1. The end datetime could be modified dynamically upon modification of start datetime:

    1. When start date is changed manually, use the currently selected duration to re-compute the end date accordingly. For instance:

      • Initial situation:
        • Start date set to 24/02/2026 01:00
        • Duration set to 1 hour
        • Implies end date set to 24/02/2026 02:00
      • Change: Start date changed to 24/02/2026 03:00
      • Provokes setting end date to 24/02/2026 04:00
    2. 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.

  2. Changing end date or duration should keep the same behavior as the current one:

    1. When end date is changed manually, select the matching duration if applicable (start date does not change)

    2. When duration is changed manually, re-compute the end date accordingly (start date does not change)

  3. Regarding coherence between start and end: if end date predates start date, I would say:

    • Either raise a UI notification
    • Or raise an error upon trial of saving
    • But do not reject input right away (upon end date modification)

    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

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: 1. **The end datetime could be modified dynamically upon modification of start datetime**: 1. When start date is changed manually, use the currently selected duration to re-compute the end date accordingly. For instance: - Initial situation: - Start date set to 24/02/2026 01:00 - Duration set to 1 hour - Implies end date set to 24/02/2026 02:00 - Change: Start date changed to 24/02/2026 03:00 - Provokes setting end date to 24/02/2026 04:00 2. 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. 2. **Changing end date or duration should keep the same behavior as the current one**: 1. When end date is changed manually, select the matching duration if applicable (start date does not change) 2. When duration is changed manually, re-compute the end date accordingly (start date does not change) 3. Regarding coherence between start and end: **if end date predates start date**, I would say: - Either raise a UI notification - Or raise an error upon trial of saving - But do not reject input right away (upon end date modification) 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
Author
Owner

@prakash-218 commented on GitHub (Feb 26, 2026):

Can I pick this up?

@prakash-218 commented on GitHub (Feb 26, 2026): Can I pick this up?
Author
Owner

@CommanderStorm commented on GitHub (Feb 26, 2026):

sure

@CommanderStorm commented on GitHub (Feb 26, 2026): sure
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#4752
No description provided.