Nobody Dares Pull the Plug: In Defense of Finally Deleting the Dead Cron Job

There's a cron job at your company that nobody remembers writing. It runs every night at 3:47 AM. It emails a CSV to a distribution list containing one person who left the organization in 2021. It has no documentation, no owner, and no known purpose. And it will outlive us all.

We don't talk about these things enough, so let's talk about them: the dead services shuffling through our infrastructure. The microservice with zero callers that still gets deployed. The feature flag from 2019 that's still checked on every request, permanently false. The queue consumer processing messages from a producer that was decommissioned during the previous administration. Technically alive. Functionally extinct. Untouchable.

Why We Can't Kill It

Here's the question that should bother you: engineers will happily ship code with known bugs on a Friday afternoon, but suggest deleting an unused cron job and watch the room go pale. We fear deletion more than failure. Why?

Because a bug has a blast radius. Deletion has a mystery radius. If the service breaks, you get a pager alert and a war room. But if you delete the thing nobody understands and something somewhere depended on it? You find out via a Slack message from a downstream team three weeks later, and the message is not friendly.

Because deletion is unglamorous. Nobody got promoted for removing code. There's no demo, no launch, no announcement blog post. "What did you ship this quarter?" "Nothing. I deleted 40,000 lines and the p95 latency dropped by half." Cue the sound of a promotion evaporating.

Because someone, somewhere, might be using it. This is the killer. The fear isn't rational — it's the software version of not wanting to be the person who throws out the box of cables that, yes, turns out to contain the one cable needed during the outage. Every engineer has been burned once, and the scar tissue is permanent.

The True Cost of the Zombie

The zombie process isn't free. It costs monitoring dashboards you have to keep explaining. It costs on-call pages at 3:47 AM when it inevitably fails, forcing some poor soul to debug a mystery with zero context. It costs the cognitive load of every new hire who reads the architecture diagram and asks, "what does this do?" — and the entire team, in unison, shrugging.

Worst of all, it costs courage. Every dead service that lingers sets a precedent: nothing here ever gets deleted. New engineers learn the local culture fast. The graveyard grows. The diagram becomes a museum. And the codebase becomes a place where nothing is ever truly over, which sounds like a quote from a war memoir, not a git history.

The Case for the Kill

Now the opinion part, and I'll plant my flag: the best code you will ever write is the code you turn off. Deletion is the only change that is guaranteed to reduce complexity. A new feature might help. A refactor might clarify. Deleted code helps always, by definition, with certainty. It cannot introduce a bug. It cannot leak memory. It cannot page anyone. It is the only diff with a 100% success rate.

So here's the protocol I've started using, and I offer it freely:

Log before you kill. Before deleting anything, add usage logging for a month. Let the data decide. Half the time you'll discover the thing is already getting zero calls and the fear was entirely fictional.

Announce the execution date. Not "we're thinking about it." A date. A deprecation email to every plausible stakeholder. Silence is consent in software, because silence is the only thing silence ever is.

Delete, don't disable. A disabled service is a zombie with extra steps. Delete the deploy config. Archive the repo. Remove the dashboard. Let it be gone, so the next archaeologist doesn't have to wonder.

And when it breaks something? Congratulations — you just discovered an undocumented dependency, which is a gift, not a failure. You found a landmine by stepping on it in a controlled setting instead of during an incident. That's a win wearing a loss costume.

Rest in Peace, Actually

The 3:47 AM cron job doesn't deserve immortality. Neither does the service nobody calls or the flag nobody flips. They persist because we let them, and we let them because deletion requires something shipping never does: the courage to be certain enough to remove.

Kill the zombie. Write the deletion commit message with pride. Some of us build the future. The rest of us, occasionally, just take out the trash — and honestly, the repo has never looked better.