Your host bills you in bytes. Nothing in WordPress counts them.

It works when your host exposes the access log inside your account as a file PHP can read. SiteGround, Kinsta and Cloudways all document exactly that, as does any VPS where the PHP user can read the log. WP Engine serves access logs through its portal and API rather than as a file, so there is nothing on disk to read; export and use the manual upload. On cPanel shared hosting the account log is normally a symbolic link pointing outside your home directory, and where a host enables open_basedir that may block the read. Auto-detect answers the question for your host in about thirty seconds and shows you every path it tried.

Measures. Both standard combined formats record the response body size as a number: $body_bytes_sent in nginx, %b in Apache. Ledger reads that field. It does not multiply request counts by an average page size, and where it cannot read a log at all it says so rather than producing a figure.

Measurement layer, and we are not claiming to be the only plugin measuring bytes. Plugins in that category count from inside WordPress on a PHP hook, and some now record response sizes measured the same way. That works, and it has two blind spots: a PHP hook cannot see a full-page cache hit, because PHP never executes on one, and it never sees a static file at all. Reading the server's log has neither blind spot. It also depends on your host in a way an in-WordPress counter does not, and it cannot block.

No, and that is deliberate. Ledger has no code path that touches a live request. Blocking is already commodity: robots.txt for the well-behaved, and crawler controls at the CDN edge, which are increasingly a free default and a better place for it anyway. What none of those can tell you is what the traffic cost or what blocking it saved.

Sometimes, and Ledger will tell you honestly when they did not. If you were inside your bandwidth allowance all month, the overage is zero and so is every attributed figure. Some hosts publish that they exclude bot traffic from billed bandwidth; tick that box and Ledger reports crawler cost as zero, because on your plan that is the truth. The byte figures stay either way, because server load is real whether or not it reaches an invoice.

From you. Ledger ships with the overage rate at zero and shows no money anywhere until you enter your own plan allowance and rate from your own invoice. It never guesses a hosting price. Costs are then apportioned by share of bytes, because an overage charge is levied on the total and no single consumer caused it alone.

Neither, structurally. Ingestion runs from cron or an explicit click, never on a page load, so there is no code on the visitor path. Each run streams the file with a wall-clock budget and a line budget, then saves its offset and continues later; a 4 GB log and a 4 MB log use the same memory, because the file is never held. Storage is daily rollups with a per-day URL cap and a hard retention cut, and the Ingestion tab shows the live row counts so you can hold it to that.

Ledger detects rotation by inode change, not by size or timestamp, then looks for the rotated copy across logrotate's numeric and dated suffixes, plain and gzip, and reads the tail it had not yet seen. If no rotated copy is readable, it records that the tail was not counted rather than pretending otherwise. Short host retention is an argument for the plugin: Kinsta documents about four days, SiteGround about thirty, and Ledger keeps compact rollups for up to 400.

No to both. No telemetry, no external service, no account, no API key. The only outbound capability is optional forward-confirmed reverse DNS for crawler identity, which is off by default, runs on cron, queries DNS only and caches for a week. IP addresses are used transiently for that check and never written to any table. Request lines, referers and query strings are not stored either; only the normalised path.