DEV Community: codeCrack-01

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

codeCrack-01 — Mon, 17 Aug 2026 12:12:19 +0000

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.

How a Silent Python TypeError Left Our Cloud Worker Running for 3 Days

codeCrack-01 — Mon, 17 Aug 2026 11:58:30 +0000

I thought our cloud cleanup worker was working.

It wasn't.

A small Python "TypeError" caused one of our ephemeral DigitalOcean droplets to survive for 3 days instead of ~45 minutes.

The weird part? Nothing crashed.

The cleanup loop was still running. It just silently treated the failed timestamp calculation as "0" seconds of age — so the droplet looked perfectly healthy.

And that wasn't even the only bug.

We eventually found three separate failure modes:

→ A "datetime"/"str" mismatch hidden by broad exception handling
→ Cloud resources being deleted from our tracking state even when destruction failed
→ In-memory state being used as the source of truth, meaning a restart could orphan resources

The bill?

About $5.

Not catastrophic. But the failure mode could have been.

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 entire incident, including the failure chain, what we changed, and the architecture lessons:

How a TypeError Costed 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 credits do.

We scanned our own production site and found 8 vulnerabilities. Here’s the list.

codeCrack-01 — Sun, 16 Aug 2026 15:15:13 +0000

Building software in 2026 feels surreal. With LLMs handling boilerplate, we ship features in hours that used to take weeks.

But fast shipping has a nasty side effect: it breeds overconfidence.

A few days ago, we ran an automated check against our own live marketing site (vergate.dev). We build security and diagnostic tools for a living, so we expected a clean bill of health.

We were wrong. Our scanner flagged 8 real issues in production—including missing security headers that left us exposed to basic cross-site attacks.

Dogfooding your own tool isn't a marketing gimmick. Sometimes, it's just plain embarrassing. But it taught us a crucial lesson: you can’t fix what you don't automatically measure.

What our scan actually found

Here is the exact breakdown of what slipped past us into production (and what probably exists in your current deployment right now):

1. Zero Security Headers Enabled

Our hosting provider’s default CDN edge rules didn't set baseline headers. We were shipping without:

Content-Security-Policy (CSP): Left us open to inline script injection.
Strict-Transport-Security (HSTS): Didn't force browsers to enforce HTTPS strictly.
X-Content-Type-Options: Allowed MIME-type sniffing on static assets.
X-Frame-Options: Rendered our pages vulnerable to clickjacking IFrames.

Why this happens: Framework defaults (like Next.js, Nuxt, or Astro) often expect your proxy or CDN edge (Vercel, Cloudflare, Nginx) to handle headers. If you forget to configure the edge, your app runs bare.

2. Sensitive Meta & Server Leakage

Our response headers explicitly broadcast our server stack and proxy details. Attackers use automated scanners like Shodan or Censys to query these specific signatures and exploit target-specific CVEs in seconds.

3. Cookie Missing `SameSite` & `Secure` Flags

A tracking cookie set on a subroute wasn't explicitly flagged as SameSite=Lax or HttpOnly, leaving a window open for CSRF-style cross-domain requests.

How we fixed it (in under 10 minutes)

Fixing these issues wasn't complex—it was just easy to forget.

Instead of writing custom middleware for every header, we passed the scan findings context straight into our IDE:

Edge Headers: Added a centralized header manifest in our deployment config to enforce HSTS and CSP globally.
Cookie Sanitization: Updated our cookie handler to strictly attach Secure; HttpOnly; SameSite=Lax.
Automated Gatekeeping: Wired the engine directly into our local setup so we can't merge broken configs to staging again.

Why "Vibe Shipping" Needs Automated Guardrails

When you’re moving fast or prompting AI assistants to generate full codebases, you review the UI, test the main user flow, and hit deploy. Nobody manually inspects raw HTTP response headers or cookie flags on every push.

If you want to read the full, unfiltered breakdown of our self-audit and what we learned about host edge defaults, check out our writeup: We scanned our own site and found real problems. Here's everything on the Vergate Blog.

Don't assume your deployment provider handles security defaults for you. Run a passive check on your app before your users—or an attacker—do it for you.

What’s the most embarrassing misconfiguration you’ve accidentally shipped to production? Let’s talk in the comments.

I built a website scanner because I got tired of manually checking websites

codeCrack-01 — Sat, 15 Aug 2026 15:25:32 +0000

I've been building websites for a while, and I kept running into the same annoying problem:

A site can look completely fine while quietly having:

broken SEO metadata
missing security headers
accessibility issues
bad performance
indexability problems
missing structured data
AEO/AI-search issues
dozens of other small problems

So I built Vergate — a website scanner that puts these checks into one report.

You give it a URL and it analyzes the site across things like SEO, security, performance, accessibility, and AI-search readiness, then tells you what needs fixing.

The part I care about most is that it's not supposed to be another dashboard where you get 47/100 and have no idea what to do next.

The goal is:

Scan → understand the problem → fix it.

I'm an indie developer and this is my first serious attempt at turning one of my projects into a real SaaS, so I'm currently trying to get it in front of actual developers and get brutally honest feedback.

If you build websites, I'd genuinely love to know:

What are the website checks you always do before shipping that you wish were automated?

You can try Vergate here:
Vergate.dev

Feedback—especially criticism—is welcome.

Stop babysitting your AI agents in the terminal — NockIt sends push alerts straight to your phone (Nockit)

codeCrack-01 — Wed, 05 Aug 2026 08:14:17 +0000

If you're running autonomous AI agents, fine-tuning scripts, or long background jobs, you know the drill: you hit enter, switch to another tab to work on something else, and then spend the next hour periodically flipping back to the terminal just to check if:

It finished.
It hit an unhandled exception 30 seconds after you looked away.
It's waiting on user input or a permission prompt.

Watching lines of terminal output scroll by isn't a good use of anyone's time.

To solve this for my own workflow, I built NockIt—a free, open-source, plug-and-play notification utility that hooks into your local or remote AI agents and pushes real-time alerts directly to your phone or desktop via ntfy.

Learn More: https://nockit.uk

What it does

NockIt provides a simple, zero-bloat bridge between your autonomous dev pipelines and your devices.

🔌 Plug & Play Integration: Add it to your execution loops or script completion hooks with minimal lines of code.
📱 Powered by ntfy: Uses lightweight pub/sub push notifications—no clunky enterprise webhooks or complex bot setups required.
⚡ Instant Event Pings: Receive push notifications for task completions, script failures, token budget limits, or required human-in-the-loop actions.
🔓 100% Free & Open Source: Keep your tooling local and transparent.

Test Example

Instead of keeping your terminal pinned to your screen while your agent runs through an multi-step workflow, you can trigger a push alert when key state changes happen:

import requests

def notify_dev(title, message, priority="default"):
    requests.post(
        "https://ntfy.sh/your_custom_nockit_topic",
        data=message.encode('utf-8'),
        headers={
            "Title": title,
            "Priority": priority,
            "Tags": "robot,warning"
        }
    )

# Inside your agent's execution loop:
try:
    agent.run_task()
    notify_dev("Agent Finished!", "Task completed successfully without errors.")
except Exception as e:
    notify_dev("Agent Crashed 🚨", f"Error encountered: {str(e)}", priority="high")

Ofc, no one wants to write such long code! Just set it up via a single command (requires Node Js installed):

npx -y nockit-mcp@latest setup

Give it a try

I'd love for the community to test it out and share feedback!

Live Site: https://nockit.uk

Drop a comment below and share your experience—what's your current setup for monitoring long-running background tasks or AI scripts, and what features would make your workflow easier?

Flask

codeCrack-01 — Tue, 26 Nov 2024 12:27:33 +0000