The escalation that got my attention wasn't a page from the on-call rotation, it was a DevRel Slack thread from a developer who'd been a fan of the platform for two years and was now threatening to leave. That was the moment I stopped assuming the rate limiter was working just because uptime looked fine.

A defense built during an emergency tends to stay unquestioned long after the emergency passes, because it's quietly doing its job and nobody's incentivized to revisit it. So now, any time I inherit a uniform guardrail that's been untouched for years, I check whether it's still telling apart the people it was built to stop from the people it's now catching by accident. That's the whole practice. Everything else here is just the one time I finally ran that check.

The flat per-key limit had been introduced years earlier as an emergency fix during an active abuse incident, and it worked, abuse traffic dropped to near zero overnight. Nobody had revisited it since, because it was quietly doing its job. But a rate limit that can't tell a growing legitimate customer from an attacker doesn't actually distinguish between them, it just punishes both equally, and only one of them deserved it.

I only found this because developer relations mentioned, almost in passing, that a few top-tier integrators had started building caching layers purely to dodge unpredictable throttling. That's not a security story. That's a customer building extra infrastructure to work around a system that was supposed to be helping them.

I underestimated one thing going in: security owned the anomaly signal and worried that exposing "why you were flagged" would help bad actors reverse-engineer detection. When I first proposed the dashboard, it read as a request to give away their playbook, not what I actually meant, giving legitimate developers just enough to self-correct.