4,000 requests from 19 sources and a screen that blocked nothing

Five new protective rules sat on the screen, and we were 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, we reopened the notes and spent two hours writing down what we had done. We wanted a partner or someone on the team to have a usable map for the next time a site slows down for reasons nobody can see at first.

What a bot swarm looks like

A bot swarm is a lot of automated visitors arriving in a coordinated rush. Each visitor looked fairly ordinary on its own, even though the traffic was large. 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.

The view that hid it

Our first attempt did not work. We sorted the activity by individual visitor and looked for the biggest numbers. That is the obvious thing to do when a system is struggling, and it was the wrong view. Over 90 minutes, one page received 4,000 requests from 19 separate sources. Taken one by one, those sources looked mild. Taken 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? How much of the activity on those pages comes from sources we already have reason to distrust? That gave us a pattern to examine instead of a long list of numbers, and it kept us from confusing the noisiest single visitor with the cause of the slowdown.

There was a second false start before that. The first automated reading we 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. A report can be tidy and detailed and still leave out the one thing that matters.

The 20 minutes we spent remembering

During the incident, we spent 20 minutes rebuilding access that we had set up before but never written down. We 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. We made one reference that set out the access path, the first questions to ask, and the check that had found the pattern.

The screen that only took notes

We also wrote down a finding that was uncomfortable. 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 stopping happened somewhere else, through the protective rules we had added. In plain language, the screen was a notebook, not a lock. We had assumed that a visitor on the list was being stopped, and that assumption was wrong.

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.

Why we did not automate it yet

The pattern had worked once, but we did not yet know the right line at which a warning should become an action. Automating a rule we had seen only once would have handed a machine a confidence we had not earned ourselves. AI can help sort the activity, point out a pattern, and draft the checklist. It should not decide on its own 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.

Check whether each safety screen in your business stops anything or only records what someone intended. Write down the access path and the first questions to ask before the next urgent day, so nobody has to rebuild them from memory.

dxdev LESSON · paste into your AI coding agent
LESSON: The view that finds a distributed attack is different from the per-visitor view that feels natural to check first
SOURCE: dxdev.com/everyday-ai/fix-was-not-the-five-rules
WHAT HAPPENED: A bot swarm was invisible when sorted by individual visitor, each of 19 sources looked mild on its own, but obvious once viewed by page plus how much of that page's traffic came from already-distrusted sources, revealing 4,000 requests to one page from 19 sources in 90 minutes. An earlier automated report had also been looking at the wrong system entry point and called the traffic ordinary. After five mitigation rules stopped the rush, two hours were spent writing a reference doc, including the important discovery that the screen showing "blocked visitors" was only a record of activity, not the actual enforcement mechanism, an assumption that had gone unverified until then.
THE RULE: When hunting a distributed or coordinated problem, sorting by individual actor can hide the pattern; sort by the shared target and correlate with known-distrusted sources instead. Also, a dashboard that displays "blocked" is not proof of enforcement until you've confirmed the actual blocking mechanism is what's doing the blocking.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any anomaly or incident investigation that sorts or ranks by individual actor as the primary lens, without also checking aggregate-by-target patterns that could reveal a distributed or coordinated issue.
  2. Any UI or dashboard element labeled "blocked," "flagged," or similar that has not been verified to be the actual enforcement mechanism rather than just a logging or recording view.
  3. Any incident resolved by adding mitigation rules with no follow-up written runbook capturing the access path, first diagnostic questions, and the check that found the real pattern.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.