Two years ago, on June 4th of 2018, Microsoft announced its acquisition of GitHub, a unicorn darling of the developer tools startup ecosystem, for $7.5B in stock. The announcement unearthed a wide range of opinions and pontifications, ranging from “GitHub is doomed” to “Microsoft is smart”, with many predictions about GitHub’s future. Some thought Microsoft’s growing investments in its cloud offering, Azure, might help GitHub. Could an investment by Microsoft improve GitHub’s reliability or harden them against outages like DDOSes? Have any of these predictions come true?
We set out to analyze one angle of the GitHub acquisition: Has GitHub become more reliable since its acquisition by Microsoft? Our service, StatusGator, monitors more than 700 status pages of cloud providers and SaaS companies large and small. We aggregate and normalize status page data and make it available to our subscribers however they need: in notifications by email, Slack, Teams, or webhook, and in an all-in-one status page for all service dependencies.
For more than 5 years, we have analyzed the GitHub status page constantly. Every 5 minutes, StatusGator takes a screenshot and collects relevant data about their service status. That means we are uniquely positioned to offer analysis of the downtime that GitHub themselves announce via their status page.
What does the data tell us? In the two years since the acquisition announcement, GitHub has reported a 41% increase in status page incidents. Furthermore, there has been a 97% increase in incident minutes, compared to the two years prior to the announcement. Does this actually point to a decrease in reliability? We can’t say. This could simply mean GitHub has increased its transparency, publishing to their status page more frequently.
We calculated an incident count in the 24 months preceding the announcement and the 24 months after. We classify status pages into four states: up, warn, and down, and maintenance. GitHub does not expose scheduled maintenance on their status page. For these calculations we consider an incident to be any change in status between up and warn or down.
Before the acquisition, there were 89 incidents published on the GitHub status page. After, there were 126 incidents. A 41% increase:
In the graph below, we’ve charted the incident counts by month. The left side shows the 24 months before and the right side shows the 24 months after:
We calculated incident minutes by subtracting the start and end time of time of incidents. Although not 100% real-time, StatusGator checks frequently: every 5 minutes, so status page changes are detected quickly. We counted times when the page was not in an overall up state.
In the 24 months prior to the acquisition announcement, there were 6,110 minutes of downtime. During the 24 months after, there were 12,074 minutes of downtime, a 97% increase:
In the graph below, we’ve charted the incident minutes by month. The left side shows the 24 months before and the right side shows the 24 months after:
Status Page Evolution
During these four years, GitHub has made enormous improvements in their status page information granularity and design. In December 2018, they switched from a homegrown status page to one operated by Atlassian’s StatusPage service, the most popular status page provider. In doing so, they added numerous individual component statuses. Here’s what GitHub’s status page looked like before their switch to Atlassian StatusPage:
GitHub’s Old Status Page
When they switched to their new status page format, GitHub took a huge step towards increased accountability and transparency by detailing the following individual service components:
- Git Operations
- API Requests
- Issues, PRs, Dashboard, Projects
- GitHub Pages
Over time, they have expanded and refined their component statuses. They also started showing historical data right on their status page. As you can see in their newest and most detailed status page format, it shows the following service component statuses:
- Git Operations
- API Requests
- Issues, PRs, Projects
- GitHub Actions
- GitHub Packages
- GitHub Pages
GitHub’s New Status Page
They also moved their status page to a dedicated domain, githubstatus.com, which follows a best practice we recommend to anyone who hosts a status page. All of this additional transparency, details, and historical data is a commendable effort to relay the most up-to-date information about the status of all GitHub systems. More providers of critical cloud infrastructure should emulate what GitHub has done. Your status page is useless if you don’t use it.
What can we conclude from all of this data? Objectively, we can conclude that GitHub has published their status page more frequently in the two years after their acquisition announcement. They have posted more incidents of disruption and downtime. Those incidents have been longer in duration. According to the data they provided, GitHub has been down more since the acquisition by Microsoft.
But that could be all a part of a coordinated effort to be more transparent about their service status, an effort that should be applauded.
Our goal at StatusGator is not to shame anyone for disruptions and outages. Everyone experiences unexpected downtime. We simply strive to make status page data available and accessible in more useful ways. From Slack and Microsoft Teams, to webhooks, an API, and more. StatusGator aggregates status page data and empowers you to keep your team informed.
Is your team dependent on GitHub? Consider trying out StatusGator, free for 30 days. You can get notifications about GitHub and more than 670 other services with status pages we monitor. You can receive notifications in Microsoft Teams, Slack, by email, SMS, or webhook. Our favorite feature is a Slack integration with a
/statuscheck slash command that allows querying the status of any service, right from where your team hangs out.
Try a 14-day free trial of StatusGator and let us know what you think.
More on GitHub Reliability