Planned Outages / Maintenance Banners

[bennetgallein]

Hi,

first of all - cool project and creative concept. Happy using it so far at https://status.remote-backups.com/

For my feature request I do maintenance regular, meaning there is a planned outage from time to time. Customers usually check the status page first. A banner indicating ongoing maintenance on a certain monitor would be great to communicate.
Maintenance mode should also disable notifications and uptime-checks / handling of outages (just pretend they are healthy or greyed out or something).

My idea would be to add a "alerts" section to the config, perhaps something along of this type:

export type Alert = {
  severity: "info" | "warning" | "danger" // severity mode, indicates color if color is left empty
  color: "green" | "orange" | "red" | string // predefined colorset or hex code
  title?: string // alert title
  message?: string // alert message with markdown support (would be great)
  monitors: ['fra1-1'] // related monitor IDs
  start?: Date // start date - if empty treat as now
  end?: Date // end date - if empty never ending
}

export type AlertsConfiguration = Alert[];

let me know what you think. I think I could also provide a PR but time is limited and I'm not a react native ;)

[lyc8503]

Hi, thanks for the advice.

The configuration example you provided looks a bit complicated. To simplify it a bit, I think it can be implemented like this:

1. implement a paused configuration for each monitor, when set to true, skip the monitoring of this target and gray out it in the status page, so it won't send notifications nor affect uptime.

2. implement a banner configuration, you can specify the color and text content to display the specified banner in the status page.

When you plan to maintain a server, you can set the corresponding monitor to paused and manually write a banner as a notification to inform users that the corresponding service is being maintained.

When you finish the maintenance you can manually revert the configuration and the monitor will continue to run normally.

---

There are a few more details here though: e.g. whether the page title should still show All systems operational when a monitor is paused. Maybe there should be an option to set it manually to Under maintenance.

[bennetgallein]

Hi, thanks for the feedback.

My intention behind the automation (and start- and enddates) was that you are able to prepare the full maintenance cycle.

Imagine a scenario where I plan updates and a reboot for 3PM on 3 hosts. I can do other maintenance related things before 3PM without causing issues so I do that. Then at 3PM i can just reboot the hosts. Anyone checking the status page at that time would see the maintenance banner and the corresponding hosts being in a disabled/paused state.

If this is a manual process I would be required to redeploy the status page before and after the maintenance is over, so it's basically a manual process.

---

to spin this idea further, if we keep start and end dates one could build a maintenance history for a service from the config entries if they are not removed, would also be quite cool to have.

---

Regarding the overall status I think a Partial Maintenance would be best suited (at least for my needs).

[bennetgallein]

And some quick notes on the dev-setup would be greatly appreciated! :)

[lyc8503]

to spin this idea further, if we keep start and end dates one could build a maintenance history for a service from the config entries if they are not removed, would also be quite cool to have.

I agree with this, and it would be a good idea to document the historical maintenance in the form of a configuration file. Even though the project hasn't added history incident related features yet (#92 (comment)), I think this could be a good start.

Later on this functionality could also be expanded to account for historical incidents, and we could have a page dedicated to displaying downtime (unexpected downtime or planned maintenance) after summarization.

And some quick notes on the dev-setup would be greatly appreciated! :)

Sorry to say, but since this project uses a lot of features that are tricky to configure locally (e.g. Cron/DO) and is constantly iterating, I haven't invested a lot of time in researching a good usable approach to local development at this point.

Currently I'm using wrangler to deploy directly to Cloudflare for testing and development, the project is divided into two parts: workers and pages, and you need to deploy the part that changes. Although there is no live update feature when developing the front-end, the deployment is not too slow.

Deploying Workers: Execute wrangler deploy directly in the worker folder.

Deploy Pages: In root folder, compile with npx @cloudflare/next-on-pages, then deploy with npx wrangler pages deploy .vercel/output/static --project-name uptimeflare.

[bennetgallein]

I like the path you are taking with your ideas, indeed a per-monitor page with an incident history would be awesome to have.

I see that the topic in #92 (comment) is mostly about the limit of free tier. Perhaps there is a workaround with another free product cloudflare offers?
R2 has 10GB free plus more than enough operations to store and update files. Perhaps we can save the incident history in JSON files and load them for the frontend?

[lyc8503]

I see that the topic in #92 (comment) is mostly about the limit of free tier. Perhaps there is a workaround with another free product cloudflare offers?

It's the second half that I want to quote:

According to my understanding, a status page is actually divided into two parts: the first is real-time monitoring, which provides notifications when downtime occurs. The second is the recording of historical events, which records and displays information on the occurrence time, duration, reason and other information of the event after each event. Real-time monitoring can be automated, while event recording requires manual and timely intervention to be written.

I didn't implement the second part of this before, but now it might be possible to implement it in a way that is stored in a configuration file.

If we write incident history in the config file, we don't need to store it in the database and we don't exceed the free tier limit.

[bennetgallein]

Ah I see. I think that could be a good balance.

One could theoretically automatically create an incident based on real-time monitoring, but enriching it with a reason and so on requires manual work. For example cachet / cachet-monitor automatically creates incidents but those are most of the times a bit useless since it's basically just the error message.

Since the config file is a js file, we do have the option to import from other files correct? Thinking about many monitors with many incidents (or a big history) the config could grow a bit out of control, but with includes this would be easily seperatable

[bennetgallein]

this is my current state. I'm not a frontend guy so theres some work todo to make it look actually good, but I think it demonstrates what I envision.

I've added this to the config:

maintenances: [
    {
      title: 'Planned updates',
      body: 'The corresponding monitors will shutdown for a maintenance period in order to apply operating system updates. Please be patient',
      monitors: ['fra1-1', 'fsn1-1'],
      start: new Date('2025-04-19 00:00:00Z'),
      end: new Date('2025-04-19 01:00:00Z'),
      color: 'red',
    },
  ],

the monitors can be loaded by ID so we can show the other name and reference it by id and also a check to test if the current time is inbetween the maintenance start-stop would be good to have. Regarding that? Is there some static compiling going on or does SSR work as expected?

---

I've also did some cleanup with types for the config and moved them to a types/ folder

[lyc8503]

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.

[bennetgallein]

#101 - PR here. Let's continue discussion there(?) to have everthing in one place.