# deadcode

Published articles for deadcode.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## We Gave Our Service More CPU -- and It Took Down Production

DevFeed: [We Gave Our Service More CPU -- and It Took Down Production](<https://devfeed.tech/articles/we-gave-our-service-more-cpu-and-it-took-down-production-26517.md>)

Original publisher: [Read original article](<https://medium.com/engineering-housing/we-gave-our-service-more-cpu-and-it-took-down-production-7e3926669e94?source=rss----3a69e32e2594---4>)

Author: PULKIT GARG

Published: 2026-08-10T06:48:00Z

Content type: article

Language: en

Sources: [Housing.com](<https://devfeed.tech/sources/housing-com.md>)

Topics: [cpu](<https://devfeed.tech/topics/cpu.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [incident](<https://devfeed.tech/topics/incident.md>)

Tags: [cpu](<https://devfeed.tech/tags/cpu.md>), [deadcode](<https://devfeed.tech/tags/deadcode.md>), [incident](<https://devfeed.tech/tags/incident.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [parallelstream](<https://devfeed.tech/tags/parallelstream.md>), [production](<https://devfeed.tech/tags/production.md>), [production-outage](<https://devfeed.tech/tags/production-outage.md>)

### AI overview

An incident report explains how increasing a service from 1.5 to 2.5 CPU cores caused a lead-creation API to stop creating leads across the web and app. The investigation found that Kubernetes CPU requests and limits had been treated differently: the request was reverted, but the elevated limit remained, leaving the service in its broken state.

### Source excerpt

Every engineer has a story about the "harmless" change that wasn't. This is mine. Ours didn't start with a bad deploy. No risky feature flag, no sketchy migration, no Friday-evening hotfix. It started with a change every ops playbook calls safe: We gave a struggling service more CPU. We went from 1.5 cores to 2.5 cores. That's it. And within minutes, our lead-creation API -- the thing that turns a visitor tapping "Contact" into an actual business lead -- stopped creating leads. Entirely across web and app. The twist that cost us hours: the more CPU we threw at it, the worse it got. This is the story of why -- and the three-year-old landmine we stepped on. The incident in five beats -- including the "rollback" that changed nothing.Act 1: The pager goes off It's mid-afternoon. Leads flatline. Not "slow" -- zero. New listings get intermittently sluggish too. Instinct says: something downstream is down. A database. A cache. Elasticsearch. So we do what everyone does -- we start pointing fingers at infrastructure: Is Postgres healthy? Looks fine. Redis? Fine. Elasticsearch? Fine. Is the DB connection pool exhausted? Let's bump it -- 20 connections to 30. Let's add a live monitor to watch it. We even stopped incoming traffic to let the system breathe. Nothing helped. And here's the detail that made everyone's head hurt: CPU utilization wasn't even high. We had just added CPU. The graphs looked calm. The service looked healthy by every metric we trusted. Yet requests went in and never came out. When your dashboards say "fine" and your users say "down," you're not looking at the right layer. Act 2: The rollback that didn't roll back Eventually someone said the obvious thing: "Wasn't the only change today the CPU bump? Roll it back." So we did. Or we thought we did. We reverted the CPU request. The service kept failing. What we missed -- and what burned an embarrassing amount of the incident -- is that Kubernetes has two CPU knobs: request -- what the scheduler reserves for you limit