---
title: "Five New Rules Stopped the Bot Rush. Writing Down Why Took Two More Hours."
canonical: https://dxdev.com/blog/2026-04-24_fix-was-not-the-five-rules/
datePublished: 2026-04-24
---
Five new protective rules sat on the screen, and I was trying not to treat them as the ending. The rush of traffic had stopped. The service was answering normally again. The computer load had come back down. It would have been easy to close the notes, count the five rules as the fix, and move on.

Instead, I reopened the notes and spent two hours writing down what I had done. I was not trying to make the story sound clever. I was trying to give a partner or someone on the team a usable map for the next time a site slows down for reasons nobody can see at first.

The scary term here is a **bot swarm**. It means a lot of automated visitors arriving in a coordinated rush. The hard part was not that the traffic was large. The hard part was that each visitor looked fairly ordinary on its own. A real person may open a page once or twice. A harmful script can make the same kind of request over and over, but spread that work across many separate visitors so no one of them looks dramatic.

My first attempt did not work. I sorted the activity by individual visitor and looked for the biggest numbers. That is the obvious thing to do when a system is struggling. It was also the wrong view. Over 90 minutes, one page received 4,000 requests from 19 separate sources. Taken one by one, those sources looked mild. Looked at together, on the same page, they told the whole story.

What finally helped was asking two plain questions at the same time: which pages are being hit, and how much of the activity on those pages comes from sources we already have reason to distrust? That gave me a pattern to examine instead of a long list of numbers. It also kept me from confusing the noisiest individual visitor with the real problem.

There was a second false start before that. The first automated reading I reviewed had been looking at a different entrance to the system from the one being hit. It called the problem ordinary load because it could not see the relevant activity. That was a useful reminder for me. A clear answer is only useful when it is based on the right part of the business. A report can be tidy, detailed, and still leave out the one thing that matters.

The other cost was time. During the incident, I spent 20 minutes rebuilding access that I had set up before but never written down. I had to remember how to reach the system, where to read the activity records, how to compare the three entry points, and how to test what a visitor would actually receive. None of those jobs was difficult by itself. Together, in the middle of a problem, they turned into a memory test.

That is why the two hours the next morning mattered more than the five rules. I made one reference that set out the access path, the first questions to ask, and the check that had found the pattern. I also wrote down a finding that was uncomfortable but important: a screen that appeared to show blocked visitors was not actually doing the blocking.

The screen kept a useful record and counted activity. It looked like a control panel. But the real stopping happened somewhere else, through the protective rules I had added. In plain language, the screen was a notebook, not a lock. I had assumed that a visitor on the list was being stopped. That assumption was wrong.

That distinction matters outside a website. Most businesses have screens with comforting labels: approved, restricted, flagged, paused, protected. Some change what happens next. Some only record what someone intended to do. If nobody checks which is which, the business can feel protected while nothing has changed for the customer or the team.

I did not turn this into an automatic system straight away. The pattern had worked once, but I did not yet know the right line at which a warning should become an action. Automating a rule I had only seen once would have given a machine confidence that I had not earned myself. AI can help sort the activity, point out a pattern, and draft the checklist. It should not quietly decide to block real visitors or change a live protection.

The five rules may hold until a different kind of traffic arrives. The map is what lets us start in the right place when it does. On Monday, ask someone on the team one question: **If this safety screen says a visitor is blocked, how can we prove within five minutes that the person is actually being stopped and that a real customer is not?** If there is no clear answer, write down the path from the screen to the real action before the next urgent day forces you to reconstruct it.