---
title: "The Firewall Rule That Paid for Itself"
canonical: https://dxdev.com/blog/2026-09-28_upstream-filtering-outsized-metric-impact/
datePublished: 2026-09-28
---
Our main site averaged 37.7 error-minutes a day before the rate-limit and bot-blocking rules went in at our CDN edge. Over the last five weeks it averaged 3.3, and yesterday it logged zero. That's a 91% drop, and the application code didn't change.

We track this in a downtime report that a script refreshes on demand. When I refreshed it, I retyped the ticket that had asked for a fix to NO CODE and closed it with the five-week numbers attached. The change was made in the edge rules, and the ticket type should say so.

## What the rules were

Rate limiting and bot blocking, applied at the edge in front of the origin. I don't have the thresholds in my notes, so I won't quote any.

What I do have is the shape of the change. Application fixes tend to remove specific errors and leave a residue. This one dropped the whole curve by roughly a factor of eleven, from 37.7 to 3.3 a day, without a deploy to the application.

## Three things I'd repeat

- **Write down the baseline.** The 91% is a claim we can make only because the report still had 37.7 a day sitting there from before. Without the prior number, "it feels quieter" is all we'd have.
- **Close the ticket as what it was.** Retyping it to NO CODE put the result in the record for the next person who assumes every error metric moves through a pull request.
- **Log which rule fired.** The gap I can't close from my notes is how much of the 34-minute daily drop came from bots and how much from plain volume limits. We measured the outcome across five weeks, but we never split it by rule. If you copy this, log which rule fired on each blocked request from day one, so you can answer that question later.