Ability to show "upcoming" scheduled maintenance on status pages prior to maintenance window starting #1617

Open
opened 2026-02-28 02:27:18 -05:00 by deekerman · 15 comments
Owner

Originally created by @doublehelix on GitHub (Dec 12, 2022).

⚠️ Please verify that this feature request has NOT been suggested before.

  • I checked and didn't find similar feature request

🏷️ 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

Originally created by @doublehelix on GitHub (Dec 12, 2022). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ 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_
Author
Owner

@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 ;)

@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 ;)
Author
Owner

@Kevinvincentals commented on GitHub (Apr 20, 2023):

+1 on this feature. Would be awesome to show upcomming maintenance instead of ongoing.

@Kevinvincentals commented on GitHub (Apr 20, 2023): +1 on this feature. Would be awesome to show upcomming maintenance instead of ongoing.
Author
Owner

@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.

@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.
Author
Owner

@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?

@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?
Author
Owner

@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!

@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!
Author
Owner

@prom00 commented on GitHub (Nov 22, 2023):

We would appreciate this too!

@prom00 commented on GitHub (Nov 22, 2023): We would appreciate this too!
Author
Owner

@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.

@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](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc), as always: [Pull Requests](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md) welcome.
Author
Owner

@prom00 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.

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.

@prom00 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](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc), as always: [Pull Requests](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md) welcome. 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.
Author
Owner

@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.json is the file detailing how to connect to the db
  • it is created in the first step of the frontends' setup wizard

Note that npm run dev serves the frontend under localhost:3000 and the server under localhost:3001

@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.json` is the file detailing how to connect to the db - it is created in the first step of the frontends' setup wizard Note that `npm run dev` serves the frontend under `localhost:3000` and the server under `localhost:3001`
Author
Owner

@prom00 commented on GitHub (Nov 23, 2023):

I tried starting it with
npm run dev
AND
npm run start-frontend-dev
AND
npm run start-server-dev

None 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): I tried starting it with ```npm run dev``` AND ```npm run start-frontend-dev``` AND ```npm run start-server-dev``` None 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.
Author
Owner

@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.

@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.
Author
Owner

@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.

@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.
Author
Owner

@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 ^^

@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 ^^
Author
Owner

@Alex-0293 commented on GitHub (Aug 29, 2024):

This is really necessary for us

@Alex-0293 commented on GitHub (Aug 29, 2024): This is really necessary for us
Author
Owner

@CommanderStorm commented on GitHub (Aug 29, 2024):

@Alex-0293 Feel free to contribute a PR
github.com/louislam/uptime-kuma@562de6abb4/CONTRIBUTING.md

@CommanderStorm commented on GitHub (Aug 29, 2024): @Alex-0293 Feel free to contribute a PR https://github.com/louislam/uptime-kuma/blob/562de6abb458a1708124f4589ab79e730913dad9/CONTRIBUTING.md
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#1617
No description provided.