带有页面的事件-部署延迟
2026年8月6日07:00 UTC，一次配置变更意外降低了处理GitHub Pages部署的服务容量。随着接下来几小时流量增加，部署流水线的延迟逐渐上升。<br /><br />12:09 UTC，延迟超过了告警阈值，团队开始调查。我们回滚了无效配置，并采取了额外缓解措施，包括减少状态部署处理以降低Redis集群负载。延迟于15:40 UTC恢复正常水平。<br /><br />客户影响发生在11:34至15:32 UTC期间。在此期间，我们未能处理约128,000次部署。<br /><br />我们已更新告警，以便更早检测到处理延迟升高，并在延迟导致部署处理失败时立即通知我们。我们确认此次事件未被可用性指标完全捕获。未来几天，我们将更新GitHub Pages可用性的衡量方式，以便今后此类事件能被准确反映。
原文On August 6, 2026, at 07:00 UTC, a configuration change inadvertently reduced the capacity of the service that processes GitHub Pages deployments. As traffic increased over the following hours, latency in the deployment pipeline progressively increased. <br /><br />At 12:09 UTC, latency crossed the alerting threshold and the team began investigating. We reverted the invalid configuration and applied additional mitigations, including reducing status deployment processing to lower the load on our Redis cluster. Latency returned to normal levels at 15:40 UTC. <br /><br />Customer impact occurred from 11:34 to 15:32 UTC. During this period, we failed to process approximately 128,000 deployments. <br /><br />We have updated our alerts to detect elevated processing latency sooner and to notify us immediately when latency causes deployment processing failures. We've confirmed this incident was not fully captured by our availability metrics. In the coming days, we'll update how GitHub Pages availability is measured so incidents like this are accurately reflected going forward.
影响Pages的服务降级已得到缓解。我们正在监控以确保稳定性。
原文The degradation affecting Pages has been mitigated. We are monitoring to ensure stability.
我们正在调查有关Pages性能下降的报告。
原文We are investigating reports of degraded performance for Pages
关于这些数据
事件从哪来？
全部来自各厂商官方状态页的公开接口，由本站每 5 分钟同步一次，保留最近 90 天。事件标题、时间、影响级别与更新记录均为官方原文，本站不做改写；点详情页底部的链接可回到厂商原始记录核对。
为什么有的服务查不到历史？
本页只收录对外提供官方状态页的服务。没有公开状态页的厂商（多数国产大模型属于此类）无法取得可信数据，本站不做自建拨测去猜，因此也不会出现在状态总览里。
持续时长怎么算？
按官方标注的开始时间到恢复时间计算；尚未恢复的事件按「至今」计算并标为进行中。跨天的事件在状态条上会覆盖它经过的每一天。