# A quarter of my server log is the site calling itself, and I caused half of it

> A sixth to two fifths of my origin log is the site requesting wp-cron.php from itself. There is a ceiling, and my own testing pushed it up.

Source: https://visibleorigin.com/wp-cron-fills-your-access-log/
Published: 2026-10-07

---

**The short version.** Between a sixth and two fifths of the requests in my server's access log are the site calling itself. Not visitors, not crawlers — WordPress asking WordPress to check whether any scheduled work is due.

The days with the highest proportion are the days I spent measuring the site. **Every request I made to take a reading triggered another request that then appeared in the reading.**

The mechanism is documented, the volume is bounded by a lock nobody mentions, and the interesting number turned out not to be the one I set out to find.

## What is in the log

All figures below come from the origin server's access log for this site. That matters: a CDN sits in front, absorbing an unknown share of visitor traffic, so these are not "the site's requests" — they are the requests that reached the machine.

| Day | Requests in log | To `wp-cron.php` | Share |
| --- | --- | --- | --- |
| 11 Sep | 2,989 | 798 | 27% |
| 12 Sep | 2,104 | 854 | **41%** |
| 13 Sep | 897 | 148 | 16% |
| 14 Sep | 1,220 | 194 | 16% |
| 15 Sep | 542 | 112 | 21% |
| 16 Sep | 447 | 70 | 16% |

Every one of these arrived from the loopback address: the server making a request to itself.

A 41% day is a striking number and it is the wrong one to lead with, because the floor is more informative than the peak. **Even on the quietest day, one request in six is internal.**

## Why it is not "on every visit"

The usual summary is that WordPress runs its scheduler on every page load. That is close enough to be repeated everywhere and not accurate enough to explain a log.

WordPress's [own documentation](https://developer.wordpress.org/plugins/cron/) describes the design: the scheduler handles *“time-based tasks”* such as checking for updates, and it works by looking at a list of scheduled tasks to see what is due. What it does *not* do is fire a request every time somebody loads a page. Several conditions have to line up first, and one of them is that **something is actually due**.

Which reframes the question. The volume is not a function of how many people visit. It is a function of how often the queue has something waiting — and that is a property of what your plugins schedule, not of your traffic.

### The queue on this site

| Recurrence | Events |
| --- | --- |
| Non-repeating | 13 |
| Daily | 12 |
| Every 12 hours | 4 |
| Hourly | 3 |
| Weekly | 2 |
| Every 15 minutes | 1 |
| Every 5 minutes | 1 |
| **Every minute** | **1** |

37 events. The last row is the one that sets the rhythm; the twelve daily ones are irrelevant to volume.

**One event recurring every minute means the queue is essentially never empty.** It belongs to a background task library shipped inside two of this site's plugins — not something I scheduled, and not something that shows up in any plugin's settings screen.

So the shape of the answer is: a library I did not install directly, scheduling work every sixty seconds, guarantees that almost any request arriving at the right moment will trigger an internal one.

## The ceiling nobody mentions

There is an upper bound, and knowing it turns a scary number into a measurable one.

WordPress holds a lock while a scheduler run is in progress, and on this installation that lock lasts sixty seconds. One spawn per minute, at most, gives a hard ceiling of **1,440 per day**.

| Day | Spawns | Share of the 1,440 ceiling |
| --- | --- | --- |
| 12 Sep | 854 | 59% |
| 11 Sep | 798 | 55% |
| 14 Sep | 194 | 13% |
| 16 Sep | 70 | 5% |

On the busiest day the site used 59% of the maximum possible. The average gap was about 101 seconds, which is an average and not a cadence.

That reframes it again. 854 internal requests sounds like something has gone wrong. **59% of a ceiling that exists by design sounds like what it is: a busy day, working as intended.**

Before writing any of this I checked the hypothesis that would have made it a genuine fault — a task that fails, never clears, and leaves the queue permanently overdue. **Zero events on this site are overdue.** The scheduler is healthy; it is simply being asked often.

Reading a log well enough to tell internal traffic from real traffic is the first thing [the free check](https://visibleorigin.com/services/#free-check) has to do before it can report anything about crawlers, with the requests written out so you can repeat them. Getting a site's scheduling off the request path entirely is part of [the technical SEO and server work](https://visibleorigin.com/services/).

![Bar chart of wp-cron internal requests per day against a ceiling of 1440, peaking at 854 on the day the author made 1520 requests to the site while measuring it, and falling to 70 on a quiet day](https://visibleorigin.com/wp-content/uploads/wp-cron-self-requests.webp)
Read against the ceiling rather than in isolation, the alarming day becomes an ordinary one. The dotted line is what the lock allows.

## The part that is my own fault

Look again at the two highest days. On 11 and 12 September I made 1,300 and 1,520 requests to this site myself — measuring crawler behaviour, checking headers, verifying caches.

Each of those requests was eligible to trigger a scheduler spawn. **The days I was busiest measuring the site are the days the site generated the most internal traffic, and that internal traffic then appeared in the measurements I was taking.**

This is not a subtle effect. On 12 September, 854 of 2,104 logged requests were the site calling itself, and the reason there were so many is that I was making the other 1,250.

It has a practical consequence for anybody analysing their own logs: **your own testing is in the data, and it is not neutral.** It inflates the totals, it changes the ratios, and it does so most on exactly the days you are looking hardest. [I have written before about acting on a symptom without reading the mechanism](https://visibleorigin.com/scheduled-post-published-itself/); this is the version where the act of looking produces the symptom.

## What to do about it

### Move the scheduler off the request path

WordPress documents the standard arrangement: [hook the scheduler into the system task scheduler](https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-schedule) instead, because as the documentation puts it, WP-Cron *“does not run continuously, which can be an issue if there are critical tasks that must run on time”*. The internal requests stop and the work runs on a fixed schedule.

### Know what the alternative constant does before using it

There is a second constant that changes how the scheduler is triggered, and [the configuration reference](https://developer.wordpress.org/apis/wp-config-php/) frames it as a remedy for a specific symptom — scheduled posts not publishing. It is not a general-purpose fix, and reaching for it because you dislike a number in a log is how sites end up with two half-configured scheduling mechanisms.

### Check the spawning system is actually working

The command line tool has a dedicated [test for this](https://developer.wordpress.org/cli/commands/cron/test/), which reports on the spawning system rather than on individual events. It is the right first question, because a scheduler that is not being triggered at all produces a very quiet log and a very broken site.

### Exclude yourself before you count anything

Filter the loopback address and your own before computing any ratio. If you skip this, the first thing your numbers describe is your own afternoon.

The method, and where it stops being able to tell you anything, is in [how I measure](https://visibleorigin.com/how-i-measure/). If your log is mostly noise and you want to know what is left underneath, [send me a domain](https://visibleorigin.com/contact/).

## WP-Cron and loopback requests: frequently asked questions

### Does WordPress run its scheduler on every page load?

No. Several conditions have to be satisfied, and the decisive one is whether any task is currently due. A site whose queue is usually empty spawns rarely; one with a task recurring every minute spawns often.

### Why are there so many requests from 127.0.0.1 in my log?

Because the scheduler is triggered by the site requesting a file from itself. Those requests are internal by design and are not visitors, so they should be excluded from anything you report as traffic.

### Is a high number of these requests a problem?

Not by itself. There is a ceiling set by an internal lock — on a default installation, one per minute, or 1,440 a day. Compare your figure with that ceiling rather than reacting to its size.

### How do I tell whether my scheduler is stuck instead of busy?

List the scheduled events and look for ones whose due time has passed. A healthy queue has none. A permanently overdue event will trigger a spawn on nearly every eligible request and never clear.

### Should I disable it and use a system cron?

That is the documented arrangement for sites that need tasks to run on time, and it removes the internal requests. It also means the work stops if you remove the system entry, so it is a change to make deliberately rather than to tidy a log.

### Does my own testing affect these numbers?

Yes, substantially. Each request you make while investigating is eligible to trigger a spawn. On this site the two busiest days for internal traffic were the two days I spent measuring it.

## The general shape of this

I started this wanting to know why a number in my log was high. The number was not high. It was 59% of a documented ceiling on the day I hammered the site hardest, and 5% on a quiet day, and the difference between those two figures is mostly me.

The useful habit is smaller than a rule: **before asking why a figure is large, find out what the largest it could be is.** A count with no ceiling attached invites alarm; the same count expressed as a fraction of its maximum usually answers the question by itself. The ceiling here took one lookup, and it converted a mystery into arithmetic.

And the second half is harder to systematise: the instrument was in the sample. There is no clever fix for that beyond knowing it happens and filtering yourself out first — which is one more thing to check before believing a number about your own site.

Filtering yourself out of the log is only the first surprise it holds; another is [five rented machines requesting the same 272 paths, which turned out not to be about me at all](https://visibleorigin.com/probe-list-is-not-about-you/).