mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
Ability to show "upcoming" scheduled maintenance on status pages prior to maintenance window starting #1617
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#1617
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 @doublehelix on GitHub (Dec 12, 2022).
⚠️ Please verify that this feature request has NOT been suggested before.
🏷️ Feature Request Type
UI Feature
🔖 Feature description
I'd love the ability to show Planned / "Scheduled Maintenance" notifications on status pages when we know there is a maintenance window scheduled. This way we can schedule maintenance any time in advance and people visiting the status page can see all upcoming maintenance windows so they can prepare.
At the moment, the "Maintenance" notification only appears on the status pages after the maintenance window has started.
✔️ Solution
A checkbox to "Show advanced maintenance schedule" when adding a scheduled maintenance window.
When checked, this maintenance period will appear on the status page as "Upcoming scheduled maintenance" and display the scheduled date/time with optional description.
It could even translate the timezone based on the users browser settings.
❓ Alternatives
No response
📝 Additional Context
No response
@grodzik commented on GitHub (Apr 20, 2023):
That would be really useful feature. Actually I came here looking for exactly this, if there is such feature already, or maybe there are some open issues regarding this topic. @louislam any chance for this feature. I'm not JS developer myself, so can't help much with coding, only with eventual testing ;)
@Kevinvincentals commented on GitHub (Apr 20, 2023):
+1 on this feature. Would be awesome to show upcomming maintenance instead of ongoing.
@wucherpfennig commented on GitHub (May 4, 2023):
I was asked this question today. this would actually make sense to be able to announce maintenance windows.
@grzywek commented on GitHub (May 16, 2023):
👍
I was a bit surprised when I scheduled a maintenance for the first time and I couldn't get it displayed on the status page. That was actually one of our main goals to have it working that way.
And should be actually pretty simple to implement.. Anyone?
@1fexd commented on GitHub (Sep 17, 2023):
I would also love to see upcoming scheduled maintenance windows on the status page. It would also be great if creating such a scheduled maintenance would send allow sending a notification. Anyway, love uptime kuma!
@prom00 commented on GitHub (Nov 22, 2023):
We would appreciate this too!
@CommanderStorm commented on GitHub (Nov 22, 2023):
@prom00 @1fexd @evolucja @wucherpfennig @Kevinvincentals @grodzik
Please refrain from posting
+1/ requests for updates things on issues, as this makes issue-management harder.Issues are for discussing what needs to be done how by whom.
We use 👍🏻 on issues to prioritise work, as always: Pull Requests welcome.
@prom00 commented on GitHub (Nov 22, 2023):
I've been looking into the source, but I'm having issues on getting the system started. (db-config.json file missing).
I think we don't need major changes for this to be implemented, but I could be completely wrong with this not knowing the complete source.
@CommanderStorm commented on GitHub (Nov 22, 2023):
The getting started docs apparrently is not quite up to date/ a better warning message might be needed:
db-config.jsonis the file detailing how to connect to the dbNote that
npm run devserves the frontend underlocalhost:3000and the server underlocalhost:3001@prom00 commented on GitHub (Nov 23, 2023):
I tried starting it with
npm run devAND
npm run start-frontend-devAND
npm run start-server-devNone of the above seemed to generate a db-config.json file.
Then I got back to thinking, I started the frontend only and accessed it via the browser. It then stated the server wasn't running.
Then I started the backend and reloaded the browser and finally managed to create the database.
It's totally missing this critical step in the docs. The docs even state you can both start them together, but then it errors out.
Think we better change this message: [SETUP-DATABASE] INFO: db-config.json is not found or invalid: ENOENT: no such file or directory, open 'data\db-config.json'
Where it hints the user to open the frontend to generate a database.
@prom00 commented on GitHub (Nov 23, 2023):
Another error throwing up trying to get this running:
Trace: [Error: insert into `stat_daily` (`down`, `monitor_id`, `ping`, `timestamp`, `up`) values (0, 3, NULL, 1700697600, 29) - SQLITE_CONSTRAINT: NOT NULL constraint failed: stat_daily.ping] { errno: 19, code: 'SQLITE_CONSTRAINT' }This happens everytime a monitor is tried at the heartbeat interval. Happens for every monitor configured.
@nliechti commented on GitHub (Mar 13, 2024):
We would like to have this feature as well and would be open to implementing it for our needs.
The whole thing would get quite complicated with recurring and cron expression windows. I would only implement it for "Single Maintenance Windows" with a special "Publish in advance" flag when scheduling the maintenance.
Would this be acceptable to merge upstream? If not I would be open to discuss the scope or how we could implement it without an explosion of complexity.
@CommanderStorm commented on GitHub (Mar 13, 2024):
I don't think it is necessary to limit this to single maintenance windows (as far as I remember said code, that would be more work), but that is something that you will obviously look at during implementation.
I am fine with recurring maintenance being included and not being included.
A point that will come up during the implementation is where to place this.
A good idea how to introduce this while allowing future PRs to introduce further details about incidents would be preferred. See https://github.com/louislam/uptime-kuma/pull/1253 for further details.
If this is acceptable to merge upstream is not clear.
I don't currently see any PRs which this would directly conflict with.
We don't give out blanket merges. Mergability would depend on how this feature looks and if it has bugs ^^
@Alex-0293 commented on GitHub (Aug 29, 2024):
This is really necessary for us
@CommanderStorm commented on GitHub (Aug 29, 2024):
@Alex-0293 Feel free to contribute a PR
github.com/louislam/uptime-kuma@562de6abb4/CONTRIBUTING.md