55,000 fake signups in one night: a bot-detection post-mortem

Jaime trejo — Wed, 24 Jun 2026 20:23:42 +0000

We sell bot detection. Last night I opened our database and found 555 pages of fake signups. This is the honest write-up: what broke, why it's embarrassing, how we fixed it in one night — and the accidental circuit breaker that saved our email domain.

The discovery

Tuesday, 11pm. I open the Supabase table editor to check something unrelated and the developers table feels… heavy. Every row has the same name: "🎁 Dene Hemen! 5K Lira Bonusunu Yakala" — Turkish for "Try it now! Grab the 5,000 Lira bonus." Casino spam. I scroll. Page 2. Page 40. Page 555.

55,388
FAKE SIGNUPS

58,618
JUNK VERIFICATION LOGS

12
REAL ACCOUNTS (OUCH)

Yes you read the third number right. We're early. For a few minutes our growth chart looked incredible, as long as you didn't read the names. The irony was not lost on me: bots flooded the signup form of a bot-detection product.

-Root cause #1 — no rate limiting on signup

Our public API endpoints had per-plan rate limiting from day one. Our marketing site signup? A honeypot field and good intentions. Honeypots only catch bots polite enough to render your form — these ones POSTed the endpoint directly, thousands of times, and never even saw the hidden field.

A honeypot is a screen door. Rate limiting is the lock. We had the screen door.

-Root cause #2 — we dogfooded wrong (the embarrassing one)

Here's the part that stings. Our signup did call our own bot-detection API on every registration. So why didn't it catch 55,000 bots?

Because we called it with just a userId — no behavioral signals. useHUMA scores behavior: mouse movement, keystroke cadence, scroll rhythm, touch patterns. Given zero signals, the engine returned a neutral score. Neutral cleared our threshold. Every bot passed.

We installed our own security camera and pointed it at the wall. If you dogfood your product, dogfood it the way you tell customers to use it — or it's decoration.

-Root cause #3 — every fake signup sent a real email

Each registration fired a verification email. 55K signups = 55K attempted sends to fake addresses — the kind of bounce storm that gets a sending domain blacklisted. What saved us? Our email provider's free-tier daily cap. The limit we'd been mildly annoyed by quietly refused to send the flood. Domain reputation: intact.

Sometimes the constraint you resent is the circuit breaker you never installed.
The fix (same night)

Four changes, shipped before going to bed:

Per-IP rate limit on signup (5/min) — reusing the same atomic counter our API already used. ~12 lines.
Lifecycle emails (drip, trial reminders) now filter email_verified = true. Spam rows never get emailed again.
Deleted 113K junk rows (after pattern-matching them safely).
A weekly habit: one SQL count query. Monitoring you don't look at is monitoring you don't have. Update, same week: shipped. Our signup now collects full behavioral signals client-side and scores them on every registration — and a submission carrying no signals at all gets rejected outright. Our own form finally uses useHUMA the way we tell customers to. The camera points at the door.

DEV Community: Jaime trejo

55,000 fake signups in one night: a bot-detection post-mortem