[Feature Request] Ability to end Maintenance Mode early

I cannot for the life of me find anyone or any references regarding taking a host (or hosts) out of Maintenance Mode early. So I’m requesting we have that functionality added please. Both for individual hosts, as well as selecting many (any scale) to come out of Maintenance. (with note functionality, user issuing function, stuff like that for auditing)

Please! :slight_smile:

1 Like

Okay I found a hacky-ish way to do this by going to the Scheduled Maintenance section (under the Alerts menu) and setting the end time to a minute before $now.

But a button to end maintenance singular/many would be very handy please!

+1 for this. Just a way when you click “end now” it just auto sets the end time to now would do the trick.

This is actually a bit more complicated. If you put a device in maintenance mode, a Scheduled Maintenance is created, and only this host is associated. But you can also associate device groups and/or location … or a super-wild mixture :wink:

So if you’re at the device settings and click sth. like “End Maintenance”, the corresponding Scheduled Maintenance must be altered. But how? Remove the device association would work, but in case of a device group or location, how should it be changed (there is no direct exclusion feature) … and if you just end such a maintenance, other devices would be affected as well, probably without prior knowledge.

Sadly you cannot just link the maintenance because there is not even an appropriate URL for this (afaik); editing happens “within” the maintenance list view, through “modern website magic”.

Suggestion: Simply show the name of the maintenance(s) that are affecting the device. If there is only one, and this devices is directly associated, you could offer a button to remove this associaton (“End maintenance for this device”). The affected maintenances should be part of the detail page, it is cumbersome to always have to change.

If the Maintenance scope is defined for a group or multiple hosts in some way, present to the user something along the lines of…

“By ending this Maintenance early you are ending it for all these other hosts that are in-scope for this Maintenance, are you sure you want to do that?” (and list all the hosts), then if they hit Yes, ends for all, No, doesn’t end early.

That’s one way to handle it IMO.

Another way to handle it, is if we want to allow ending Maintenance Early for (an) individual(s) when a group was originally selected, is to update the Maintenance Window to explicitly declare all the hosts in the group(s) selected, but as individuals, and of course not include the specific host(s) that you were ending the Maintenance early for. IMO should be fully achievable.

So this is achievable in a few different ways that I see.

Can’t you just delete the maintenance window?

1 Like

That also deletes the record of occurrence, which in most cases is undesirable for audit/tracking purposes… assuming I’m understanding your thought accurately here.

The value to me ending Maintenance early (for some/all targeted host(s)) is that monitoring/metrics/alerting resumes when the “work I was doing in that window” is done.

There are times the “work” could be completed a lot earlier than the scheduled maintenance, and the person making decisions authorises (or wants) to end said maintenance window early as all “milestones” are achieved (so far as one can tell).

In an example scenario where “work” is complete hours early (let’s say it went way better than expected) ending the Maintenance Window early, while also keeping the record of it, means any problems after that point in time can be alerted, and metrics gathered.

In my experience, not being able to end the Maintenance Window early (for some/all of the target hosts) creates a window where metrics aren’t gathered (I’ve witnessed this in some cases, but unsure if it’s reproducible) and alerts don’t happen.

So let’s say the “work” of a project is complete hours before the end of the Maintenance Window, and we “can’t” end it early. In that time, a problem in another area could arise, and alerting would not happen because the relevant host(s) are still in Maintenance. This could tangibly delay any action to said alerts/metrics/etc in an avoidable way.

====

I also want to add, that in my opinion, I’d prefer a way to end the Maintenance Window early for part/all of the host(s) targeted without modifying the end date/time, but if part/all are ended early, add some sort of record which and when were ended early. But keep the initially scheduled end date/time unmodified, so that way any post-analysis can accurately identify “okay so we aimed to end here, but all/part ended here” so future planning can adapt (better planning?), or perhaps uncover other planning issues.

====

Bit of a mouthful, sorry, just wanted to expand on aspects of the value I see here. :slight_smile:

1 Like

@BloodyIron
Please note: Right “ending” a device maintenance simply deleted the scheduled maintenance, just like murrant suggested. So that would indeed “delete the record of occurrence”.

If you want to keep the maintenance, the feature would have to update the maintenance and setting a new end timestamp instead of deleting the whole dataset, right? (The warning message should probably still be displayed)

But anyway: In case of larger device groups (in our case could very well be hundreds at times), the messages gets “polluted” quite a bit. Not sure if this would be too helpful.

My suggestion:

  • The main page for scheduled maintenance should allow filtering by schedule_id
  • The device edit page links to this very view, making it easy to find the right maintenance and then simply edit it. You can change the end time to one being in the past. It only has to be later then the start time.

Yes, it is no one-click, but this probably more “secure” because the danger of a no-brain-one-click should be lower. And least one could say you had more information and still messed up ;D

Ah, so you guys are encapsulating your business tracking into the maintenance window history. Interesting.

I’m not sure the per-device ending early is on the table, but it would be fairly trivial to modify the maintenance end time if someone wanted to try to tackle that.

I’m not currently sure what the best option/method is from my perspective at this point, I’ve mostly been trying to lend useful thoughts on the matter so that we can hopefully arrive at something better than we have now. Even if maybe more improvements happen further down in time or something like that. :slight_smile:

I’m not currently tying this to business-specific tracking, however I’m anticipating that could be a thing in the not-so-far future for me or my clients. I’m also trying to be a good responsible IT Admin/Architect and not destroy records of change or stuff like that :stuck_out_tongue_winking_eye:

1 Like