{
  "video_id": "reddit_1vttlns",
  "channel_slug": "programming",
  "channel_handle": "r/programming",
  "title": "The August 17 outage, and the work ahead",
  "url": "https://www.reddit.com/r/programming/comments/1vttlns/the_august_17_outage_and_the_work_ahead/",
  "external_url": "https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/",
  "upload_date": "20260820",
  "published_at": "2026-08-20T19:35:06+00:00",
  "transcript": "\n\n--- Top Comments ---\n\n\n[182 upvotes] > Neither outage was caused by a code or configuration change. Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity. Since April, monthly commits have grown from 1.4 billion to 2.9 billion. That growth explains the pressure on our systems, but it does not excuse these outages.\n\nAt the end of the day, programmers and operations must have a seat at the table. It can't be management and executives saying jump and everyone else jumping without even asking how high. If there is a genuine capacity problem, there are mitigation options available but first we need to be candid. There are already throttles available and maybe we can tighten them a little before slowness turns into failures.\n\n[63 upvotes] All jokes aside, everyone should read this. It's a very interesting incident caused by cascading failures and scaling limitations by Istio sidecars. Great lesson to increase resiliency via things like circuit breakers to allow failing systems to recover to avoid worsening the problem \n\n[50 upvotes] GitHub simply can't provide free repos any more",
  "transcript_chars": 1168,
  "ingested_at": "2026-08-21T01:30:17.414681+00:00",
  "source": "reddit",
  "yt_meta": {
    "score": 159,
    "upvote_ratio": 0.97,
    "num_comments": 31,
    "author": "Successful_Bowl2564",
    "is_self": false
  }
}