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 we refreshed it, we retyped the ticket that had asked for a fix to NO CODE and closed it with the five-week numbers attached.
What the rules were
Rate limiting and bot blocking, applied at the edge in front of the origin. Our notes don’t have the thresholds, so we won’t quote any.
What the notes do have is the shape of the change. Application fixes tend to remove specific errors and leave a residue behind. This one pulled the whole curve down by roughly a factor of eleven, from 37.7 to 3.3 a day, with no deploy to the application.
Three things we’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. This is the gap we can’t close from our notes: 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 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.
Keep the pre-change number for any metric you plan to improve, so the result can be stated as a figure. Record a fix that needed no code as no code, so the history shows where the gain came from. And if you add edge rules, log the rule on every blocked request from the start.
AI Skills
Use this lesson with the AI assistant you already use
A CDN edge rate-limit and bot-blocking change cut a site's daily error-minutes from 37.7 to 3.3 over five weeks, a 91% drop with no application code change. We could claim it because the downtime report still held the earlier number, and we could not say which rule did the work because we never logged that.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: Record A Baseline And Per-Rule Attribution Before Crediting A Change
SOURCE: dxdev.com/blog/upstream-filtering-outsized-metric-impact
WHAT HAPPENED: The main site averaged 37.7 error-minutes a day before edge rate-limit and bot-blocking rules were added, then 3.3 a day over five weeks, and zero the day before the refresh. The drop could be claimed as 91% only because the downtime report still held the earlier baseline. The ticket that asked for a fix was retyped to NO CODE and closed, since the change was made in the edge rules. The rules never logged which one fired per blocked request, so the drop cannot be split between bots and volume limits.
THE RULE: Record a baseline and per-rule attribution before making a change, so you can later prove and explain its effect.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Does the report that will judge the change hold a recorded pre-change baseline?
2. Does each blocking or rate-limit rule log which rule fired on every blocked request?
3. Is a change made in configuration recorded in the tracker as configuration, not as code?
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
