How often does a public site actually get probed

When did you last look at your own server's access log? People who have looked usually remember being startled once. If you have never looked, it is your turn now.

4,959 attempts in one week

Every morning at 04:00 the AI working inside miraiGen.™Cube tallies up our suspicious inbound traffic. Counting the most recent week — 16 to 23 October 2026 — gives this:

• Distinct sources: 30
• Total attempts: 4,959
• Per day: roughly 700

What we expose is a corporate site and an online shop. Nothing conspicuous. Even so, something is out there probing about 700 times a day.

To be precise about what the number means: this is not a count of attacks. Almost none of it is a real attack. It is machinery guessing at whether a given file happens to be there. All 30 sources are recorded as having failed to reach anything.

That number is larger than our traffic from genuine prospects. More machines come looking for something than people who actually want to see what we make. It is ironic, and it is the reality of putting anything online.

This is worth paying attention to. "Our site does not get many customers, so we have nothing to worry about" does not follow. Whoever is probing is not checking whether you have customers. They work through lists of domains by machine, so a site nobody has heard of receives the same volume. If anything, the quieter the site, the less likely anyone is in the habit of reading the log — which is where it goes unnoticed.

Sixty per cent are looking for the same file

Broken down by what they were after, the distribution is lopsided.

Over sixty per cent are hunting for .env — the file that holds database passwords and API keys, and that is supposed to live outside anything served. If it can be read, the contents leave without anyone having to get into the server.

The method is crude. Not just .env but .env.1, .env.backup and similar near-misses, tried one after another. One source accounted for 1,469 attempts, which is simply the same file brute-forced through a list of name variations.

So what is being hunted is not a vulnerability. It is things left behind and things never deleted: the file you meant to remove before going live, the backup parked next to the original, the development copy that rode along to production. Guessing by machine is easy, so with enough targets something eventually lands.

What we changed about looking at it

Tallying is nothing special. What we changed is comparing against yesterday. Each morning the previous day's record is diffed and three things are reported separately:

• Sources appearing for the first time
• Counts that have gone up
• Paths that returned content — evidence that the server answered one of these probes

The third is the real point. How many times you were probed matters very little. Being probed is the baseline condition of being online, and you cannot stop it. What matters is only whether something came back. Watching the totals will never show you that. Only the comparison with yesterday tells you "as of today, this path is returning something".

One more observation. This traffic only gathers on the surfaces exposed directly to the internet. Anything used purely inside the company never appears here. Our own business platform sits on the internal network, so it does not show up in this table at all. Reducing what you expose pays off in that sense too.

In summary

• Check that .env and other config files are not inside a served directory. It is the most-hunted location and the most expensive to lose
• Do not park backups next to production files. Names like .env.backup are being guessed verbatim
• Delete what you no longer use. A dormant WordPress install or a development tool left in place is additional surface to be probed
• Look at your log once. Looking changes nothing by itself, but it tells you what actually needs defending

You cannot reduce how often you are probed. You can reduce how much comes back when you are.

← Back to Thoughts　All posts