to do next / ideas / roadmap

lexoyo commented 9 years ago

Contributions welcome :octocat: ..and let me know what seems important to you

optimize

[ ] when an URL never got up, remove it after a while - warn the user maybe

docs

[x] check that Monitoshi can be plugged in Zapier to send emails or a tweet - it works fine
[x] check that Monitoshi can be plugged in huginn to send emails or a tweet - it works fine and this is open source software :cupid:
[ ] write a guide on how to setup Monitoshi with Zapier to send emails or a tweet
[ ] write a guide on how to setup Monitoshi with huginn to send emails or a tweet

UI

[ ] A route to display the user's monitors, and maybe some stats (could be http://monitoshi.lexoyo.me/user/580df32bc68272aae01ee9). In each email, remind the user about his route. Then add links to enable/disable each monitor like in the debug page.

bagdes

[x] Add a "up" or "down" badge -
[ ] Add a badge "up since"
[ ] Add a badge "99.9% uptime"
[ ] Add a badge with the loading time

alert types

[x] Web hooks would be great to use in conjuction with Zapier or Huginn to take actions in case of an URL changing status (service up or down)
[x] send emails with smtp, pop3, imap directly
[ ] bot to replace emails: slack, mattermost, facebook workplace... the bots should probably be able to create monitors

integrations

[ ] a great idea from this comment: "find another problem that monitoshi can solve and build an offer around that specific issue. Like allowing marketer to automatically pause their CPC campaigns on adwords or Facebook when their site is down."
[ ] try to hook to bip.io in order to take actions when a service goes down - and this is open source software
[ ] try to hook to Stashboard in order to make status pages with only free software
[ ] try to hook to mailchimp and use nice email templates like this
[ ] silex: during publication, if the user define his domain name, propose to monitor

monitor types

(other that the current ping)

[ ] full page load: use phantomjs or Slimerjs to compute page load time including assets, scripts, fonts...
[ ] ftp
[ ] dns
[ ] tcp
[ ] ssh
[ ] smtp, pop3, imap
[ ] mysql
[ ] other like cpu, memory, etc. which would need to include a Monitoshi library in the monitored app

Other

[ ] in the debug page, log the time between pings
[ ] docker container at docker hub
[ ] Did you consider using the timing of the ping and maybe setup an alert when a service is slower than a user-defined threshold? Or maybe send daily(/weekly/monthly) report with the average, min & max response time.

JbIPS commented 8 years ago

Did you consider using the timing of the ping and maybe setup an alert when a service is slower than a user-defined threshold? Or maybe send daily(/weekly/monthly) report with the average, min & max response time.

lexoyo commented 8 years ago

:+1:

alexanderadam commented 6 years ago

An docker container at docker hub would be nice.

lexoyo commented 5 years ago

Hi @ all Here is an article which might interest you about a survey I did on the users of my instance of Monitoshi

5 things I learned about Monitoshi users

lexoyo / Monitoshi