A tiny TypeError. A 3-day cloud bill. Three bugs hiding in plain sight.

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

We had a little cleanup worker whose job was simple:

Create an ephemeral DigitalOcean droplet → use it → destroy it after ~45 minutes.

Except one of those droplets didn't get the memo.

It survived for 3 days.

The weird part?
Nothing crashed.

Our cleanup loop was still running normally. But a tiny Python TypeError was being swallowed by broad exception handling.

The timestamp calculation failed.
The fallback value became 0.
And suddenly, a 3-day-old droplet looked like it was 0 seconds old.

So the reaper happily decided:
Nothing to clean up here.

But that wasn't the only bug.

Once we dug deeper, we found three separate failure modes:
→ A datetime / str mismatch hidden by broad exception handling
→ Cloud resources being removed from our tracking state even when destruction failed
→ In-memory state being treated as the source of truth, meaning a restart could orphan resources

The bill?
About $5.
Not catastrophic.
But the failure mode could have been.

And that's what made this bug worth writing about.

The biggest lesson wasn't:
"Be careful with Python types."
It was:
Never let your cleanup system silently fail closed when the thing you're cleaning up costs money.

We wrote up the complete incident, including the failure chain, fixes, and the architectural lessons we took away:
👉 How a TypeError Cost us Cloud Credits

If you're running ephemeral infrastructure, background workers, or anything that creates cloud resources dynamically, this is the kind of bug worth finding before your cloud credits do.