We hear a lot of war stories from the teams we work with. Horror stories about cloud bills, surprise overages, and the infrastructure decisions that seemed perfectly reasonable at the time.
This one comes from Erik Dasque, CTO at Allure Security. It involves a junior developer, a Kubernetes CronJob, and a recurring bill that, if not caught, would have happened on a yearly basis. We’re sharing it with his permission (with only light editing to protect the innocent):
The cloud always collects its $2,000 tuition fee.
We had a junior dev — let’s call him Alex. Alex needed to disable a deprecated Kubernetes CronJob.
Did he use suspend: true? No.
Did he comment out the manifest? No.
Alex decided to outsmart the scheduler. He set the schedule to:
1 1 1 1 1
His logic: “It runs at 1:01 AM, on the 1st of January, but only if it’s a Monday.” He proudly explained this would execute once every ~7 years, and he was “totally okay with it running once a decade as a substitute for disabling the cron — which he didn’t know how to do.”
Here’s the problem. In standard cron — and Kubernetes — the Day of Month and Day of Week fields are a UNION, not an intersection. It doesn’t mean “Jan 1st AND a Monday.” It means “Jan 1st OR any Monday in January.”
The result:
Jan 1st, 2026: Job runs.
Jan 5th, 2026 (First Monday): Job runs again.
We caught the spike after the cloud bill jumped $2,000.
It would be easy to blame a lack of foresight here. Except — I’ll come clean. A senior team member, long since moved on, made the exact same mistake with the exact same 1 1 1 1 1 syntax three years ago.
We are literally paying a recurring “Lack of Cron Knowledge Tax” every few Januaries.
The Union Problem, Briefly
Erik’s telling of this story is funny. It’s also worth unpacking, because the underlying mechanic trips up more engineers than you’d expect. Including, as he notes, a very senior one. For anyone who hasn’t run into this particular quirk before, here’s what’s happening under the hood.
A standard cron expression has five fields: minute, hour, day of month, month, day of week. Most people assume that specifying both a day of month and a day of week creates an AND condition. Run on this day, in this month, if it’s also this weekday. That’s the intuitive read.
It’s wrong. Per the cron specification, when both fields are restricted — meaning neither is set to the wildcard * — the scheduler treats them as OR. The job runs on the specified day of month, and also on every matching weekday in that month, regardless of whether the dates overlap.
So “1 1 1 1 1” doesn’t mean “1:01 a.m. on January 1st, if it’s a Monday.” It means “1:01 a.m. on January 1st, or 1:01 a.m. on any Monday in January.” In most years, that’s three or four additional runs nobody planned for.
This behavior is documented in Kubernetes CronJobs, and it’s the kind of thing you don’t know until you know. By then, you’ve usually already paid the tuition.
What you should actually do
If you need to disable a Kubernetes CronJob, the right move is suspend: true in the spec. One field. Takes effect immediately without deleting the resource or losing your job history. If you’re done with it entirely, delete the manifest and be done with it.
What you should not do is try to schedule your way out of the problem. The scheduler will find a way to run.
The cost picture
$2,000 is not a catastrophic number. For most engineering teams, it’s noise — the kind of thing that lands on a bill and gets written off before anyone goes looking. That’s exactly the problem.
Code-level waste rarely looks alarming in isolation. A deprecated job here, an over-provisioned service there, a misconfigured schedule collecting its fee every few Januaries. None of it trips an alarm. All of it adds up.
In CloudZero’s 2026 FinOps in the AI Era survey report, code optimization remained flat as a cost-reduction tactic — 28% to 29% year over year — despite its proven outsized impact.
And at KubeCon 2025, OpenAI’s Fabian Ponce shared how a single line of code change cut CPU usage by half in their Fluent Bit platform. One fix. 50% reduction. Engineering efficiency wins tend to be multiplicative where commercial levers are incremental.
The cron knowledge tax is a smaller-scale version of exactly that. The job wasn’t expensive. Nobody had it on their radar. It just ran — twice in January, every few years — and collected its fee quietly on the way out.
That’s the signature of code-level waste. It doesn’t show up on the roadmap. It shows up on the bill, and only if someone is watching the bill closely enough to notice a spike that, in the grand scheme of monthly cloud spend, looks like rounding error. Erik’s team found theirs. A lot of teams don’t.
Visibility Has To Come First
Allure caught this because the anomaly surfaced. A cost spike, a bill that looked different, something that prompted someone to go looking. Once they were looking, the fix was trivial.
That’s almost always how it goes with code-level waste. The fix is easy. Finding it is the hard part.
You need to know something moved before you can ask why. That means cost visibility at a granular enough level to catch a $2,000 CronJob anomaly and not just track aggregate monthly spend trending in the right direction. Aggregate spend can look fine while individual services quietly drain budget in the background.
Most cloud cost management practices are built for the former. Budgets, forecasts, chargeback reports. All are useful, all operating at a level of abstraction that a misfiring CronJob can hide behind indefinitely.
The teams catching these issues are the ones with instrumentation close enough to the metal to see when a specific job ran twice in January when it was supposed to run once a decade. That level of visibility doesn’t happen by accident. It requires deliberate allocation. Tagging, attribution, and tooling that connects spend back to specific services, teams, and workloads.
Once you have it, the fixes are fast. The cron knowledge tax gets paid once, not every few Januaries. Just ask Erik.
The Cloud Cost Playbook
The step-by-step guide to cost maturity
