maintenance mode

[bennetgallein]

Hi,

as talked about - here a rough first draft.

Things I've changed so far:

• Added types/ folder and types for the config(s)
• moved the uptime.types.ts into the types folder and removed redundant. It might be possible to completly remove it, I was just lazy with the extension there.
• Autoformatted files (I dont know why it did that but my zed should be configured to accept the eslint file, let me know)

Point I'd like to have:

1. Make this look better - the cards have different widths due to the non-dynamic width of the green/red bars
2. Make the displayment dynamic, depending on the start/end time IF they are present (added a TODO in the code)
3. test with multiple active alerts
4. link monitor-id in incident with monitor to load display name
5. decide how to handle monitor checks and notifications for monitors that are in maintenance mode

closes #100

[bennetgallein]

this is my current state

I think this is good overall~ I may have some minor detail changes if you're willing to initiate a PR when it's done.

Regarding that? Is there some static compiling going on or does SSR work as expected?

I think I've disabled SSR for most of the components, and generally you don't need to worry much about that. (IIRC there's also a clear warning in the console when there's a problem with SSR)

Maintenance mode should also disable notifications and uptime-checks / handling of outages (just pretend they are healthy or greyed out or something).

I'm now not quite sure if we should continue to monitor targets during scheduled maintenance though.

I'm thinking that if we've already displayed a notice of scheduled maintenance prominently on the homepage, maybe we can continue to monitor targets as usual (only disable notifications). While this may result in a decrease in overall availability, it is also true that scheduled maintenance does in fact decrease the availability of the service. This would also give users a better idea of the actual state of the service, rather than one that appears healthy but is actually unavailable.

copying over from the issue to discuss further about the notification handling and stuff.

For that to work maintenances config object would need to be available in the worker correct? Since the worker writes to KV and the Frontend API load from KV. I don't want a duplicate maintenances object in both the pageConfig and workerConfig, so perhaps we can also import the pageConfig in the worker, then we have access to all the necessary data (start, end - and if not set) for the monitors?

[lyc8503]

For that to work maintenances config object would need to be available in the worker correct? Since the worker writes to KV and the Frontend API load from KV. I don't want a duplicate maintenances object in both the pageConfig and workerConfig, so perhaps we can also import the pageConfig in the worker, then we have access to all the necessary data (start, end - and if not set) for the monitors?

Although this doesn't cause any problems at the moment, I would recommend not importing pageConfig directly in the worker. (Importing an object means that all of its content are included in the compilation output, and if you import workerConfig in the pages project, this will result in the disclosure of private data in workerConfig.)

Perhaps we could put the maintenances object at the top level alongside pageConfig and import this object in both the worker and the page.

[bennetgallein]

Yes, I was thinking about that as well.

The problem I see is backwards compatability. If we extend the config with values that don't have a default we will break setups that don't have it unless there is a fallback value (due to the imports). Perhaps we can have a config/base.ts file which is the main point to load from and fills defaults which basically just re-exports the uptime.config.ts values?

[bennetgallein]

I've pushed something which I builds. I've not tested anything more since I have to go now, but perhaps you can have a look and give feedback if that's something that could work.

[lyc8503]

Yes, I was thinking about that as well.

The problem I see is backwards compatability. If we extend the config with values that don't have a default we will break setups that don't have it unless there is a fallback value (due to the imports). Perhaps we can have a config/base.ts file which is the main point to load from and fills defaults which basically just re-exports the uptime.config.ts values?

I think this is not necessary as UptimeFlare now is not considered "stable", no config compatibility is ever guaranteed. Users have to manually modify their config when updating if necessary, that's exactly what users should expect from "unstable" software.

Also, it looks like your auto-format is a little bit aggressive and causes many changes, could you please turn it off for now so that it won't affect review.

[bennetgallein]

For formatting, are you using prettier or eslint or something else? Reverting the formatting changes is easier when I know which format we are using :)

[lyc8503]

For formatting, are you using prettier or eslint or something else? Reverting the formatting changes is easier when I know which format we are using :)

The .prettierrc.yaml config file was already in the repository before, but I didn't always strictly follow it, my fault, sorry 😂

I have run npx prettier . --write and committed a new commit to the main branch, so if you run prettier as well, you should be able to rebase your branch to main without too many conflicts.

[bennetgallein]

Yep, needed to rebase but does seem to be alright now. I was busy with other stuff but will look into integrating the maintenances object into the worker now

[bennetgallein]

https://feat-maintenance.uptimeflare-tqg.pages.dev/ this is the current state.

I have two things where I need your help. Perhaps you can have a look at the [1] in the image, where the box is not as wide as the card below. Also I did not test in the non-grouped setup. I don't quite understand the width logic there.

I've also added the code in the worker but I don't have notifications setup (other monitoring for that) so I cannot test that.

Regarding the icon marked with [2], I don't know if we perhaps want to choose another icon here. Let me know what you think.

[lyc8503]

I have two things where I need your help. Perhaps you can have a look at the [1] in the image, where the box is not as wide as the card below. Also I did not test in the non-grouped setup. I don't quite understand the width logic there.

I've also added the code in the worker but I don't have notifications setup (other monitoring for that) so I cannot test that.

Regarding the icon marked with [2], I don't know if we perhaps want to choose another icon here. Let me know what you think.

I had a quick review with your code, it looks good to me.

I will spend some time testing it and fix the width problem (maybe today or tomorrow). The width logic is a little bit complicated as the status bar below will dynamically decide its count based on screen width. It's not hard to fix though, I will commit my fix directly to this PR.

Regarding the icon I think a triangle warning mark is better than a circle, I will change it too.

[bennetgallein]

I was also thinking that we can have the date-range in the top right of the card and perhaps have it collapsable if there are multiple maintenances. Would make it a bit more compact i think

[lyc8503]

I was also thinking that we can have the date-range in the top right of the card and perhaps have it collapsable if there are multiple maintenances. Would make it a bit more compact i think

I don't think it's very important, and having multiple systems in maintenance at the same time is probably less common. Less compact is acceptable to me as long as there are no obvious typographical errors.

I don't quite understand the width logic there.

I've fixed this in my commit, and now the alert automatically shrinks with the width of the page, all you need is a maxWidth. (You can refer to the live demo on https://status.lyc8503.net/)

I've also added the code in the worker but I don't have notifications setup (other monitoring for that) so I cannot test that.

Also I did not test in the non-grouped setup.

I haven't tested it yet, I'll do a full test and some clean ups when you think you're done, but I'm guessing that the ungrouped monitors won't be affected by this alert box.

[bennetgallein]

not quite there yet, see the gray box on the right :D

I'll do some formatting in the alert box in a minute

[lyc8503]

not quite there yet, see the gray box on the right :D

I'll do some formatting in the alert box in a minute

Oops... I specified two margins and they conflict.

[bennetgallein]

I'll remove that, gotcha :)

[bennetgallein]

this is with one maintenace

multiple.

https://feat-maintenance.uptimeflare-tqg.pages.dev/

[bennetgallein]

I've also moved the code to a separate maintenace component to have less clutter in the overall status and perhaps we can reuse that on a /:monitor page later on

[lyc8503]

Moving the time to the top right corner looks good and really makes it more compact.

multiple

I'm not a big fan of the collapsed design though, the user doesn't get to see the alert prominently at first glance when entering the page, and I'd probably be inclined to remove the collapsed dropdown box when merging and have all the alerts vertically aligned.

I was thinking of adding a close button in the top right corner so users could hide the alert (but it would come back when the page auto-refreshes), and the top right corner is now occupied by the time, so it might be okay to leave it as it is.

[bennetgallein]

Yep, I agree. In my mind it was a bit cooler than it come out in reality, i'll remove it again.

[bennetgallein]

looks like this now with multiple

[bennetgallein]

Do we want to change the Overall System Status or leave as is?

[lyc8503]

Do we want to change the Overall System Status or leave as is?

If there is already an obvious alert, I think we can leave it as is.

[bennetgallein]

Alrighty - then I'm happy with this PR. Do you have anything else that needs to be done?

[vinhegewald]

LGTM

[lyc8503]

Why is start and end of a maintenance optional?

I think a scheduled maintenance should have a defined start and end time (so that it's easier to show the timeline later).

[bennetgallein]

Yes, if not specified then the banner is always shown. This way you are free to add a "on demand" maintenance when stuff breaks. For example you could add an indefinite maintenance windows if something in your homelab breaks (lol) :D

[lyc8503]

Alrighty - then I'm happy with this PR. Do you have anything else that needs to be done?

Also LGTM, I may have a few more minor modifications(probably some variable naming and config file changes) as well as testing. I'll probably make another commit afterward.

My HomeLab went down yesterday and my two backups didn't quite work, I'm now rescuing data from one of my VMs 😥. I may continue this in a day or two.

[bennetgallein]

Alright - take your time. Backups are only worth something if they are tested :D Learned that the hard way as well. I don't want to advertise but I might know someone who could help out :)