从3月16日开始，GitHub平台因为数据库问题，接连几天出现服务不稳的状况，而官方现在提出说明，表示服务不稳的状况，是因为MySQL集群中资源竞用所造成，因此在服务高峰的时候，影响GitHub大量服务和功能的性能。目前GitHub正在努力解决这个问题，会于之后的可用性报告进一步说明。
GitHub在3月16日22点06分的时候，发现MySQL数据库在高峰时段负载增加，而这导致数据库代理达到了最大连接数，官方解释，这个数据库由多个服务共享，并接受大量的读写流量，因此在中断期间，所有写入操作都无法进行，包括Git操作、webhook、拉取请求、API请求、问题发布、GitHub Packages、GitHub Codespaces、GitHub Actions和GitHub Pages服务。
官方指出，该事件似乎与峰值负载，再加上特定情况下的查询性能不佳有关。GitHub的MySQL集群使用典型的主要与副本执行实例配置，以实现高可用性，其中只有单一主要节点能够执行写入，集群的其他部分则由提供读取流量的副本执行实例组成，GitHub借由故障转移使用健康的副本执行实例，来解决服务中断的问题，并对这段时间与查询性能相关的流量模式展开调查。
但是相同的问题却在3月17日又出现一次，官方观察到MySQL集群，出现与前一天相同的高峰流量模式和负载，由于还无法查明和解决出现查询性能问题的根本原因，官方决定在问题变严重之前先采取行动，主动进行故障转移，但没想到这个举动产生另一种负载模式，反而在主节点上造成连接问题，尽管GitHub重置连接，但应用程序仍无法连接到MySQL集群。通过找出负载模式后，官方实例索引来解决主要节点的性能问题。
接着在3月22日和23日都接连发生同样事故，官方在数据库代理中激活内存分析，希望进一步掌握高峰负载期间所出现的性能特征，并且限制webhook流量避免出现高峰流量，而这两天，GitHub同样必须在连接发生中断后，执行故障转移来恢复服务。
GitHub在高峰负载时段，审核特定数据库的负载模式，并根据审核的结果，进行一系列性能修复工作，这些工作包括将流量转移到其他数据库，以减少负载并且加速故障转移的时间，并且审查变更管理程序，官方解释，因为变更管理程序，与生产时中高负载期间的监控和变更有关。
GitHub还未找出发生连接问题的真正原因，目前先采取的措施，只能确保他们能优雅的处理中断，并且尽可能减少停机时间。