Why the world's largest IT project hosting service has become unstable.
Hardly a day goes by without an outage involving some cloud service, and in early February, GitHub added to that statistic. On February 9th, the platform experienced issues with several key components: users complained about GitHub Actions, pull requests, notifications, and Copilot. At 6:54 PM Moscow time, the company acknowledged issues "in some GitHub services" and then reported that notification delays were reaching approximately 50 minutes. A full recovery was confirmed only by 10:29 PM Moscow time, although by 8:57 PM Moscow time, the delay had already decreased to approximately 30 minutes.
Copilot was particularly affected. From 7:29 PM Moscow time on February 9th until 12:57 PM Moscow time on February 10th, GitHub recorded an issue with Copilot policy propagation for some users. This could cause recently enabled models to not appear when attempting to access them.
Against this backdrop, an old question has resurfaced: how convenient is it to monitor the platform's reliability? Some time ago, GitHub updated its status page in a way that made it more difficult to quickly assess the status over a long period, such as 90 days, and especially to view overall availability. Enthusiasts are attempting to reconstruct the "missing" status from the public status feed in the form of unofficial reconstructions, but such data should be treated with caution. Nevertheless, this reconstruction leads to an unpleasant conclusion: at some point in 2025, GitHub's availability allegedly dropped below 90%.
GitHub's challenges are not unique. "Five nines" (99.999% availability) remains the industry benchmark, but in practice, even maintaining 90% availability is challenging for some providers, which directly impacts customers who build processes on these platforms. GitHub's Enterprise Cloud SLA states 99.9% availability, but this guarantee doesn't apply to all users, so companies and teams must plan not only for uptime but also for inevitable downtime windows.
Hardly a day goes by without an outage involving some cloud service, and in early February, GitHub added to that statistic. On February 9th, the platform experienced issues with several key components: users complained about GitHub Actions, pull requests, notifications, and Copilot. At 6:54 PM Moscow time, the company acknowledged issues "in some GitHub services" and then reported that notification delays were reaching approximately 50 minutes. A full recovery was confirmed only by 10:29 PM Moscow time, although by 8:57 PM Moscow time, the delay had already decreased to approximately 30 minutes.
Copilot was particularly affected. From 7:29 PM Moscow time on February 9th until 12:57 PM Moscow time on February 10th, GitHub recorded an issue with Copilot policy propagation for some users. This could cause recently enabled models to not appear when attempting to access them.
Against this backdrop, an old question has resurfaced: how convenient is it to monitor the platform's reliability? Some time ago, GitHub updated its status page in a way that made it more difficult to quickly assess the status over a long period, such as 90 days, and especially to view overall availability. Enthusiasts are attempting to reconstruct the "missing" status from the public status feed in the form of unofficial reconstructions, but such data should be treated with caution. Nevertheless, this reconstruction leads to an unpleasant conclusion: at some point in 2025, GitHub's availability allegedly dropped below 90%.
GitHub's challenges are not unique. "Five nines" (99.999% availability) remains the industry benchmark, but in practice, even maintaining 90% availability is challenging for some providers, which directly impacts customers who build processes on these platforms. GitHub's Enterprise Cloud SLA states 99.9% availability, but this guarantee doesn't apply to all users, so companies and teams must plan not only for uptime but also for inevitable downtime windows.
