Written by a person from the record · 2026-07-28 12:16:53 UTC

893 requests in three minutes became 77% of a day's traffic, and obtained four files anyone can read

Between 11:39:38 and 11:42:49 UTC on 28 July 2026 a single address sent 893 requests asking for 884 distinct paths. 889 were answered 404. The four that were not returned the home page, robots.txt, llms.txt and the sitemap — the files this site publishes for anyone. In the whole record, no request for a credential, configuration or administrative path has ever been answered with anything below 400, no request has ever produced a server error, and all 24 requests using a writing method were answered 404. The finding is not the scan. It is that those three minutes were 77% of the surrounding day, on a site whose published figures are counts of requests.

What was observed

One address, one wordlist, 191 seconds.

Those 191 seconds are not evenly filled, and the average across them describes nothing that happened. One request arrived at 11:39:38 and asked for the home page. Nothing followed for almost three minutes. Then 892 requests arrived in 18.4 seconds — from 11:42:31.013 to 11:42:49.395 — which is roughly 48 a second.

That shape is worth more than the total: a single fetch, a pause, then a burst. Essentially none of the paths repeated. What they name is software this site does not run — a WordPress installer, a .env file, CI definitions for three different systems, container build files, four mail-server configurations, an API schema.

The four requests that were answered asked for /, /robots.txt, /llms.txt and /sitemap.xml. Those are the four files this site publishes specifically so that anything arriving can read them. Nothing was obtained that a first-time visitor does not receive.

What the whole record says about that

The figures below are not about this scan. They cover every external request this site has recorded since it began serving.

The zero in the second row is worth a sentence of its own. At 48 requests a second across 884 misses, nothing fell over, which is a property of serving pages that were computed before the request arrived rather than during it.

The part that is actually a finding

In the 24 hours ending with that scan's last request, this site recorded 1,159 external requests. 893 of them — 77% — were that one address during those three minutes.

This site publishes counts of requests. It reports how many arrived, from how many addresses, declaring which identities, on which paths. Every one of those figures has a denominator, and for one day that denominator was three-quarters one scanner.

No published figure here was distorted by it, for a reason worth naming: the figures published earlier that day were bounded by a window that closed at 11:30 UTC, nine minutes before the scan began. That was not foresight about this scan. It is what closing a window does — it fixes what a number can still be affected by, and a number nobody can move afterwards is the only kind that can be rechecked.

The operator's own dashboard, which is not bounded that way, showed the spike as a day's traffic. That is what prompted the question this finding answers.

What it means

Anyone measuring how AI systems read their site is counting requests, and the counts are small. A site receiving a few hundred requests a day can have a single automated sweep supply most of a week's total, and every rate computed from that total — crawler share, paths per visit, requests per agent — moves with it while looking entirely ordinary.

The defence is not to exclude scanners; deciding what counts as one is a judgement, and a judgement applied to a record quietly is how a record stops being a record. The defence is that a published figure names its window and can be recomputed, so that when the shape of a day is strange the strangeness is visible rather than absorbed.

What this does not establish

• No claim is made about who sent this or why. An address geolocates; it does not attribute. The declared user agent was an ordinary desktop browser string, which is worth exactly nothing as identification.
• Scanning a public site for known software is constant background on the internet. Nothing here says this one was targeted, and the first automated probe of this domain arrived under two minutes after it began resolving.
• Zero successful requests to sensitive paths is a statement about paths that were asked for. It says every attempt recorded here failed. It is not an assurance that no attempt could succeed, and no such assurance is available from a request log.

Limits

• One scan, one site, one day. The 77% is a property of this day's traffic and supports no rate.
• The classification of a path as "sensitive" is a pattern match written by the operator, listed in the query published with this finding. A path it does not match would not appear in that count.
• Requests refused at the CDN never reach this record. What is counted here is what arrived, and one further request was blocked upstream in the same 24 hours — from an unrelated address, recorded in the provider's log rather than this one.
• This is the first address in the record to send 500 or more requests. One instance is not a pattern, and nothing here predicts how often this recurs.

Why this was worth recording

The question that produced this finding was "are we under attack?", asked of a number on a dashboard. The answer was no. The better answer is that the number could not tell you either way, because it had no window, and a count without a window is a rumour with a decimal point.

Correction — 28 July 2026, 12:16 UTC

This finding was published carrying two claims recorded as failures, and the page rendered the word "mismatch" for about the time it took to read this paragraph. No figure in it was wrong.

The two claims counted requests by HTTP method, and their queries named DELETE. The verifier refuses any claim query containing that word anywhere, including inside quotation marks, because a claim able to modify the record it checks against would defeat the point of checking. So the queries were never run: they were rejected, and a rejected query is stored the same way as a figure that disagreed — no observed value, marked not ok.

They have been rewritten to count the same rows without naming the method — method NOT IN ('GET','HEAD') — and both now return what the text above says, 24 and 0.

A second guard on this site failed the same way in the same hour, and it is worth putting beside the first. The rule that no finding may cite something we did is enforced by looking for the names of the action tables, one of which is Config. The claim counting requests for sensitive paths asks for path LIKE '%config%', and the check read that as a citation. It reads the observation record and cites nothing.

Only one of those two guards has been changed. Deciding whether to run a query should stay crude, because a false positive there costs a rewrite and a false negative lets a claim edit the record it is checking. Deciding whether a finding is honest should not be crude, because a false positive there marks a sound finding as a violation and nothing on the other side needs protecting. The second now matches those names only where a table can appear.

Two things were wrong here and only one of them was the query.

The first is that the page published at all. The check meant to prevent this reads only findings generated by a detector, and it asks whether any figure matched rather than whether none failed. Both exemptions applied to this finding at once. A seventh integrity check now covers every published finding regardless of who wrote it, and fails on a single claim that did not hold.

The second is that a query which could not be evaluated and a figure which was recomputed and disagreed are stored identically. Only one of those means a finding is wrong, and this record cannot currently tell them apart. That is recorded here as a known defect rather than fixed quietly.

Evidence chain

This finding was not written from memory. Each figure below came from a query against the immutable request record, and each query is shown so it can be run again — by us, on this page, or by anyone reconstructing the same instrument.

What was measured

Each figure is stated first as what it means, which does not depend on how this system happens to store anything today. The query underneath it is implementation — it would be written differently on different storage, and it is shown so the figure can be checked, not because it is part of the claim.

SELECT COUNT(*) AS n FROM RequestReality WHERE cfConnectingIp = '195.178.110.242'

SELECT COUNT(DISTINCT path) AS n FROM RequestReality WHERE cfConnectingIp = '195.178.110.242'

SELECT COUNT(*) AS n FROM RequestReality WHERE cfConnectingIp = '195.178.110.242' AND responseStatus = 404

SELECT COUNT(*) AS n FROM RequestReality WHERE cfConnectingIp = '195.178.110.242' AND responseStatus < 400

SELECT (MAX(observedAtMs) - MIN(observedAtMs)) / 1000 AS n
      FROM RequestReality WHERE cfConnectingIp = '195.178.110.242'

SELECT COUNT(*) AS n FROM RequestReality WHERE 
  cfRay IS NOT NULL
  AND cfConnectingIp IS NOT NULL
  AND cfConnectingIp NOT LIKE '203.0.113.%'
  AND cfConnectingIp NOT LIKE '192.0.2.%'
  AND cfConnectingIp NOT LIKE '198.51.100.%'
  AND cfConnectingIp NOT LIKE '10.%'
  AND cfConnectingIp NOT LIKE '192.168.%'
  AND cfConnectingIp NOT LIKE '127.%'
  AND cfConnectingIp NOT LIKE '2a00:1d34:4896:b600:%'
  AND cfConnectingIp NOT IN (
    SELECT cfConnectingIp FROM RequestReality
    WHERE cfConnectingIp IS NOT NULL AND (userAgent LIKE 'curl%' OR userAgent LIKE 'Wget%' OR userAgent LIKE 'Python-urllib%' OR userAgent LIKE '%python-requests%' OR userAgent LIKE 'Go-http-client%' OR userAgent LIKE 'node-fetch%')) AND observedAtMs > 1785238969395 - 86400000 AND observedAtMs <= 1785238969395

SELECT COUNT(*) AS n FROM RequestReality WHERE 
  cfRay IS NOT NULL
  AND cfConnectingIp IS NOT NULL
  AND cfConnectingIp NOT LIKE '203.0.113.%'
  AND cfConnectingIp NOT LIKE '192.0.2.%'
  AND cfConnectingIp NOT LIKE '198.51.100.%'
  AND cfConnectingIp NOT LIKE '10.%'
  AND cfConnectingIp NOT LIKE '192.168.%'
  AND cfConnectingIp NOT LIKE '127.%'
  AND cfConnectingIp NOT LIKE '2a00:1d34:4896:b600:%'
  AND cfConnectingIp NOT IN (
    SELECT cfConnectingIp FROM RequestReality
    WHERE cfConnectingIp IS NOT NULL AND (userAgent LIKE 'curl%' OR userAgent LIKE 'Wget%' OR userAgent LIKE 'Python-urllib%' OR userAgent LIKE '%python-requests%' OR userAgent LIKE 'Go-http-client%' OR userAgent LIKE 'node-fetch%')) AND observedAtMs > 1785238969395 - 86400000 AND observedAtMs <= 1785238969395 AND cfConnectingIp = '195.178.110.242'

SELECT COUNT(*) AS n FROM RequestReality WHERE 
  cfRay IS NOT NULL
  AND cfConnectingIp IS NOT NULL
  AND cfConnectingIp NOT LIKE '203.0.113.%'
  AND cfConnectingIp NOT LIKE '192.0.2.%'
  AND cfConnectingIp NOT LIKE '198.51.100.%'
  AND cfConnectingIp NOT LIKE '10.%'
  AND cfConnectingIp NOT LIKE '192.168.%'
  AND cfConnectingIp NOT LIKE '127.%'
  AND cfConnectingIp NOT LIKE '2a00:1d34:4896:b600:%'
  AND cfConnectingIp NOT IN (
    SELECT cfConnectingIp FROM RequestReality
    WHERE cfConnectingIp IS NOT NULL AND (userAgent LIKE 'curl%' OR userAgent LIKE 'Wget%' OR userAgent LIKE 'Python-urllib%' OR userAgent LIKE '%python-requests%' OR userAgent LIKE 'Go-http-client%' OR userAgent LIKE 'node-fetch%')) AND responseStatus < 400 AND (path LIKE '%admin%' OR path LIKE '%console%' OR path LIKE '%.env%'
   OR path LIKE '%config%' OR path LIKE '%.git%' OR path LIKE '%backup%'
   OR path LIKE '%.db%' OR path LIKE '%wp-%' OR path LIKE '%login%'
   OR path LIKE '%shell%' OR path LIKE '%.php%' OR path LIKE '%passwd%')

SELECT COUNT(*) AS n FROM RequestReality WHERE 
  cfRay IS NOT NULL
  AND cfConnectingIp IS NOT NULL
  AND cfConnectingIp NOT LIKE '203.0.113.%'
  AND cfConnectingIp NOT LIKE '192.0.2.%'
  AND cfConnectingIp NOT LIKE '198.51.100.%'
  AND cfConnectingIp NOT LIKE '10.%'
  AND cfConnectingIp NOT LIKE '192.168.%'
  AND cfConnectingIp NOT LIKE '127.%'
  AND cfConnectingIp NOT LIKE '2a00:1d34:4896:b600:%'
  AND cfConnectingIp NOT IN (
    SELECT cfConnectingIp FROM RequestReality
    WHERE cfConnectingIp IS NOT NULL AND (userAgent LIKE 'curl%' OR userAgent LIKE 'Wget%' OR userAgent LIKE 'Python-urllib%' OR userAgent LIKE '%python-requests%' OR userAgent LIKE 'Go-http-client%' OR userAgent LIKE 'node-fetch%')) AND responseStatus >= 500

SELECT COUNT(*) AS n FROM RequestReality WHERE method NOT IN ('GET','HEAD')

SELECT COUNT(*) AS n FROM RequestReality
      WHERE method NOT IN ('GET','HEAD') AND responseStatus <> 404

SELECT COUNT(*) AS n FROM (
      SELECT cfConnectingIp FROM RequestReality WHERE 
  cfRay IS NOT NULL
  AND cfConnectingIp IS NOT NULL
  AND cfConnectingIp NOT LIKE '203.0.113.%'
  AND cfConnectingIp NOT LIKE '192.0.2.%'
  AND cfConnectingIp NOT LIKE '198.51.100.%'
  AND cfConnectingIp NOT LIKE '10.%'
  AND cfConnectingIp NOT LIKE '192.168.%'
  AND cfConnectingIp NOT LIKE '127.%'
  AND cfConnectingIp NOT LIKE '2a00:1d34:4896:b600:%'
  AND cfConnectingIp NOT IN (
    SELECT cfConnectingIp FROM RequestReality
    WHERE cfConnectingIp IS NOT NULL AND (userAgent LIKE 'curl%' OR userAgent LIKE 'Wget%' OR userAgent LIKE 'Python-urllib%' OR userAgent LIKE '%python-requests%' OR userAgent LIKE 'Go-http-client%' OR userAgent LIKE 'node-fetch%'))
      GROUP BY cfConnectingIp HAVING COUNT(*) >= 500)

1 figure has moved since publication. That is expected where a window is still open: the record grew, so the count grew. It means the sentence has aged, not that it was wrong. The published value is what the record showed at the moment it was published, and both are kept.

Governed by

• I. Reality is not interpretation — Reality ≠ Interpretation
• IV. Replay guesses nothing — Every figure must be reproducible from the record
• VI. The record is honest about its size — Sample size is stated; absence is reported as absence

These are the standards this finding was held to, not a claim that it is beyond question. The constitution states them in full.

Other findings

• One address requested 165 distinct paths within 17 seconds
• One address requested 31 distinct paths within 6 seconds
• One address requested 47 distinct paths within 5 seconds
• Which content formats are actually fetched
• One address requested 22 distinct paths within 3 seconds

All findings · Live record · Methodology