Git has become one of the most essential tools for every developer. While most developers trust in GitHub to host their git repositories, Bitbucket, and more recently Gitlab, have become worthy alternatives.
When users rely so much on those services for the everyday workflow, it became crucial for both, the providers and the users, to have almost non existing downtimes. One common approach to provide information to users about technical issues was to offer a status service (and API) for consulting the service status, similar to many other web services:
DDOS
It is still fresh in memory the huge attack against GitHub, just 1 year ago. Although rare, those kind of attacks can harm many developers who see themselves in trouble to proceed with their regular workflow (even if Git is a distributed system, it is still a problem when the Git server is down). Besides those big and somehow rare attacks, minor issues happen that may cause some itches. Now, if you work at a company like Travis, or Codacy, who depend heavily on git and the corresponding servers 24/7, every itch may become a bit more problematic.
How to detect
Currently, I find that there’s a problem on GitHub/Bitbucket when I try to do push or pull on git and it takes too much time (and probably failing). Or I just saw a post on Hacker News where someone is complaining about a problem a couple of hours ago. But I want to know as soon as those services have any minor problem. So I built a small monitor: Git Status Notifier.
Git Status Monitor
Git Status Notifier is a small and extensible monitor for GitHub and Bitbucket services (thinking about monitor Gitlab soon also) that alerts through Slack, Hipchat, or Email (using Sengrid) - and still thinking about using Twillio for SMS notifications.
It is built using one Akka actor for each provider (one for GitHub and one for Bitbucket, if enabled). Each actor makes a request to the API and compares with the previous one. If there’s any change, it will notify, using the configured channels.
How to run
It is pretty simple to run it. All configurations are defined in the configuration file:
- providers monitored
- request timeout
- time between checks
- date time format (message display)
Each notification channel must also be enabled (by default every channel is disabled). Besides that, each notification channel requires some settings, like the token, the room, etc.
Feel free to check the project on GitHub to get more details.