<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Production Incidents on Support Tools</title><link>https://support.tools/tags/production-incidents/</link><description>Recent content in Production Incidents on Support Tools</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 02 Nov 2026 00:00:00 -0600</lastBuildDate><atom:link href="https://support.tools/tags/production-incidents/index.xml" rel="self" type="application/rss+xml"/><item><title>Reddit Kubernetes Cluster Upgrade Failure: When Updates Take Down Production</title><link>https://support.tools/reddit-kubernetes-cluster-upgrade-failure-production-incident/</link><pubDate>Mon, 02 Nov 2026 00:00:00 -0600</pubDate><guid>https://support.tools/reddit-kubernetes-cluster-upgrade-failure-production-incident/</guid><description>&lt;p&gt;On March 14, 2023, Reddit experienced a multi-hour production outage affecting their entire platform during what should have been a routine Kubernetes cluster upgrade. The incident cascaded through their infrastructure, impacting millions of users and demonstrating how seemingly straightforward maintenance operations can become critical failures without proper planning, testing, and rollback procedures. This comprehensive analysis explores the technical details of the failure and provides production-ready strategies for safe Kubernetes upgrades.&lt;/p&gt;</description></item><item><title>Kubernetes Pod Startup Failures: The Too Many Services Incident</title><link>https://support.tools/kubernetes-pod-startup-failures-too-many-services-incident/</link><pubDate>Sun, 06 Sep 2026 00:00:00 -0500</pubDate><guid>https://support.tools/kubernetes-pod-startup-failures-too-many-services-incident/</guid><description>&lt;p&gt;At 3:47 AM on a Tuesday morning, our production monitoring system lit up with critical alerts: dozens of pods across multiple namespaces were failing to start. The error message was cryptic: &amp;ldquo;standard_init_linux.go:228: exec user process caused: argument list too long.&amp;rdquo; This incident would eventually reveal a subtle but devastating interaction between Kubernetes service discovery mechanisms and operating system limitations that affects large-scale deployments.&lt;/p&gt;&#10;&lt;p&gt;This is the story of that incident, the investigation that followed, and the architectural changes we implemented to prevent it from happening again. More importantly, this post provides a comprehensive guide for enterprise teams to understand, detect, and prevent this class of failure in their own environments.&lt;/p&gt;</description></item><item><title>Honeycomb Certificate Expiry Outage: 2.5-Hour Production Incident Analysis</title><link>https://support.tools/honeycomb-certificate-expiry-outage-kubernetes-incident-analysis/</link><pubDate>Tue, 04 Aug 2026 00:00:00 -0500</pubDate><guid>https://support.tools/honeycomb-certificate-expiry-outage-kubernetes-incident-analysis/</guid><description>&lt;p&gt;On April 27, 2022, Honeycomb experienced a 2.5-hour production outage that affected their entire Kubernetes infrastructure. The root cause was deceptively simple: expired certificates for the Kubernetes API server. This incident highlights a critical blindspot in many production Kubernetes deployments—certificate lifecycle management. In this comprehensive analysis, we&amp;rsquo;ll examine the incident, its root causes, and implement production-ready solutions to prevent similar failures.&lt;/p&gt;</description></item></channel></rss>