Statping: [Feature request] Notify users about maintenance

Created on 1 Jul 2018  路  6Comments  路  Source: statping/statping

I think it would be good that I can notify my users about maintenance.

I have some services with assigned email addresses. For example, XYZ site with customer_xyz email address. I plan to upgrade server or something like that, therefore I would like to define a maintenance window, 6:00 am - 7:00 am. I would send an email about maintenance and statup would use that maintenance window somehow. For example, it says, maintenance from 6:00 am to 7:00 am.

What do you think?

highly requested planned feature stale

Most helpful comment

Thanks again @asrob , I do want to implement this type of feature, but a couple things will have to come first.

  • [ ] Allow users to register (currently new users can be created, without admin perms)
  • [ ] Add maintenance to database (with timeframes of when to send)
  • [ ] Allow users to register & un-register for Statup updates. (include easy unsubscribe)
  • [ ] Create new email design for Maintenance.

I'll keep this issue open while this feature is being built out. 馃帀

All 6 comments

Thanks again @asrob , I do want to implement this type of feature, but a couple things will have to come first.

  • [ ] Allow users to register (currently new users can be created, without admin perms)
  • [ ] Add maintenance to database (with timeframes of when to send)
  • [ ] Allow users to register & un-register for Statup updates. (include easy unsubscribe)
  • [ ] Create new email design for Maintenance.

I'll keep this issue open while this feature is being built out. 馃帀

This feature is must have.

You really need a separate service to serve maintenance messages to interested parties including any end-user visible frontend. In my case, I have web application consisting of several sub-services, one of which is frontend, which is SPA and is never down. It currently shows maintenance banners (among others) but in advance of maintenance window. Since backend keeps the banner messages, and it may be down during the maintenance, frontend may not show this message during the maintenance window. Serving maintenance messages naturally fits the sentinel service like statup and should be agnostic.

This use case is somewhat different from what @asrob proposed but sending email to service owners and showing message to interested parties are just 2 different interfaces to the same problem.

I propose new API endpoints to set/get/stop/action maintenance messages plus adding services metadata.

  1. Define email metadata on your service
    Since this is not currently possible and email is arbitrary endpoint (future customer may want to use SMS for example) it should be possible to set arbitrary key/value data for any service. This could be used in ad hoc manner and could be referenced in certain actions, such as sending mail to address available in service's metadata via key email.
  2. Set maintenance window
    The attributes minimally should be message string, start datetime and estimated duration, but you could add some more such as different message formats (html, markdown, text), some metadata such as type of the maintenance (bug fix, feature release etc.), when to show the message (i.e. 2 hours before the start datetime or ASAP upon creation), more than 1 message (1 before maintenance, 1 during, 1 after the estimated duration is passed and maintenance is still active), if maintenance is ending automatically (service is healthy via status checks) or by external trigger (the fact that service is healthy doesn't mean its operational) etc.
  3. Set maintenance action
    This could be part of point 2 or separate - when the time comes, do notification action - such as email notification, POST to some web hook etc. This should be nothing by default. Action might not actually end up being only notification, eg. execute local shell script by name (which is handy to use for integration)
  4. Serve a maintenance message
    When interested party asks, so when I GET /api/maintenance/status I get two things: a message and true/false depending on where we are in the maintenance.
  5. API to stop the maintenance via external trigger
    The use case is mostly for CD pipeline, but we could have a button on web UI too.

Allow users to register & un-register for Statup updates. (include easy unsubscribe)

This is relevant only for emails, and I think most people could live with this or create email filters.

Hey all, this feature seems like a hit. Thank you for writing detailed info. I've started the process and it's already made some progress. I will update this comment with a checklist of todo's about the progress. This feature is currently implemented in version 0.79.4+

  • [x] Create Message object, with start/end times, title, description, etc.
  • [x] Show Messages for Service view (/service/1)
  • [x] Show Message on index if no service was selected (Global Message)
  • [x] Added a better date/time picker (flatpickr)
  • [x] Add /api/messages routes for viewing, creating, editing, deleting messages.
  • [x] Create a Shell Command notifier. (allows sh/bash commands to be ran as notification)
  • [ ] Trigger a Notification when Message hit Start/End timestamp
  • [ ] Messages should have allow admin to insert html, markup, or plain text for description
  • [ ] Allow users to register
  • [ ] Let users choose to receive alerts for different services.

OMG UR awesome (and FOSS FTW). Make a donate button or I will never come here again :).

Create a Shell Command notifier. sh/bash

Any cross platform solution must support Windows (Powershell/cmd). I will crereate a Chocolatey package soon.

If i have automatic planed maintenance every day in the same time (well-known time) (service always is down during this period - is normal), how can I instruct the StatPing to does not send me alert during the known maintenance period ?
Any options per service ?

This issue hasn't had any updates in a while. If this is still a problem, please create a new issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

demogorgonz picture demogorgonz  路  3Comments

bottoy picture bottoy  路  5Comments

armansaa picture armansaa  路  7Comments

tyler-public picture tyler-public  路  5Comments

asavoy picture asavoy  路  6Comments