Server logs and privacyYour host stopped logging. Your server did not.

You are now the party somebody writes to

A reader who wants to know who visited your site does not begin with your host. They begin with you, because you are the one party in the chain with a direct interest in keeping the record, a legal address that can be written to, and no transparency report to publish afterwards.

That is an uncomfortable sentence for a hosting company to write, so here is the arithmetic behind it. The inventory published here says HTTP access logs are destroyed on a twenty-four hour timer and that no address history exists anywhere afterwards. A stock web server on a machine rented from us keeps its own access log for about a fortnight, in a nightly backup for a year, and nobody set either of those numbers on purpose. The careful choice of host is undone by a default nobody read.

What one line of an access log actually holds

The default format on both common web servers has been stable for twenty-five years and almost nobody reads it as a record of a person. It is worth reading that way once, because every field below is a separate disclosure and they compound.

Seven fields, one line, written for every request a browser makes — which for a single page view is usually somewhere between twenty and eighty lines. None of it was a decision. All of it is a record.

Nine places your own stack writes a visitor down

Almost every argument about logging is about the first row. It is the one people know exists, and it is nowhere near the most revealing thing on the machine.

The last row is the one that defeats most good intentions. Shortening a log rotation from fourteen days to one changes what is on the disk and changes nothing at all about the copy that was taken at three in the morning and will be held for a year. Deleting a record you have already replicated is a change of location, not a deletion.

The two fields that give away more than the address

An address is the field everybody argues about and it is the one with the shortest useful life: it changes, it is shared, and on a mobile network it belongs to a carrier rather than a person. The two beside it are quietly worse.

The referring address describes the reader, not the request

It answers a question you never asked: where was this person a second ago. That is a private document link forwarded to them, an internal ticketing system, a mail client preview, or a page on a site they would not want joined to yours. Browsers now trim the path when the destination is a different origin, which helps — and does nothing whatever for the links inside your own site, where the full path is still sent and still written down.

The user agent is the seed of a fingerprint

On its own it is a crowd. Combined with an address, a language header, a request order and a set of accepted formats, it is frequently a single visitor across weeks — without a cookie, without consent, and without anybody having decided to track anything. This is the mechanism that makes “we only keep server logs” a weaker sentence than the person saying it believes.

Secrets end up in the log because they were in the URL

This is the failure worth reading the page for, because it is common, it is silent and it is entirely inside your control. Anything after the question mark is part of the request line, and the request line is what gets written.

• Password reset links. A single-use token in a query string is recorded in plaintext in the access log, in the backup of the access log, and at every proxy between the reader and you.
• Invitation and unsubscribe links. The same shape, longer lived, and generally not expiring at all.
• Session identifiers passed in the URL. Rare in new code, still present in old code, and a complete account takeover for anyone holding the file.
• API keys handed to a browser. A key in a query string is a key in a log, a key in a referrer sent to a third party, and a key in the reader’s history.
• The search box. A site search that submits by GET writes every query anybody has ever typed into your site next to the address that typed it.

The fix is not a logging setting. Move the value into a header or a request body, where no default format records it, and rotate anything that has already been written. A log filter that strips tokens is a second thing to maintain and it will be wrong the first time somebody adds a parameter.

What can be demanded from you, and by whom

The other guides here are about instruments arriving at a hosting company in a jurisdiction chosen for the purpose. The instrument that reaches your own logs is simpler: it is served on you, where you are, and the location of the machine is not part of the question.

• A civil demand in your own country. Somebody suing over a comment, a leak or a purchase asks the operator of the site for what the operator holds. That is you, and a fortnight of access logs is an easy thing to be ordered to produce.
• A request from a reader. Under European data protection law a person may ask what you hold about them, and an address is capable of being personal data: the Court of Justice held as much in 2016 in Case C-582/14, where a dynamic address held by a website operator was personal data because a lawful route to the subscriber existed. Retention has to be justified as well — Article 5(1)(e) says no longer than is necessary, and “the package shipped that way” is not a purpose.
• Whoever compromises the machine. The most likely reader of your access log is not a court at all. Logs are rarely encrypted, rarely monitored and almost never included in a threat model, and they sit in a predictable path on every server built the ordinary way.
• Anyone your backups reach. An off-site copy is a copy in another company, under another jurisdiction, answerable to instruments you have not read.

None of that is legal advice and this estate is not your lawyer. It is the same inventory logic applied to your side of the wire: what you cannot produce cannot be demanded of you, and everything else is a matter of whose court is asking. How that plays out on the hosting side is set out in what actually happens when the police ask a host.

Keeping less without going blind

The instinct after reading this far is to switch logging off, and it is the wrong move: a server with no logs cannot be debugged, cannot be rate limited sensibly and cannot tell you that it is currently being broken into. The goal is not zero. It is keeping the part that answers an operational question and discarding the part that only answers a question about a person.

Two of those six cost nothing at all and undo most of the exposure on this page. The last one is the one nobody thinks of and it is the reason the other five underdeliver.

The third parties logging your readers for you

Everything above concerns files on a machine you control. A browser loading your page also opens a connection to every other origin the page names, and each of those receives the address, the user agent and a referrer saying which of your pages was being read — before any consent banner has been answered, because the request has already left.

• A font served from somebody else. One line in a stylesheet, and every reader of every page is disclosed to a third party for a file you could host in the same directory as the rest of the site.
• An embedded video or map. Loaded on sight, on every page it appears on, whether or not anybody presses play.
• A chat widget or a tag manager. Present on every page by design, and able to load further code you have not reviewed.
• An error tracker. The most useful of them and the most revealing: it exists to send you the state of somebody else’s session.
• A CDN in front of the whole site. Not an argument against one — it is a reasonable trade — but it is a company that sees every request before you do, holds its own logs, and answers to its own jurisdiction.

Self-hosting the first three is usually an afternoon of work and it removes more third-party observation than any setting on your own server. It is also the part of this page that improves what your readers get rather than only what you can be ordered to produce, which is the reason to do it first. The equivalent list pointed at your own exposure rather than your readers’ is in the nine things that identify a site.

What this estate can do about it, and what it cannot

Drawing the boundary honestly is worth more than a reassurance, so here it is from this side.

• Our own HTTP access logs are destroyed on a twenty-four hour timer and there is no address history, no sign-in location record and no fingerprint that survives it. The complete list of what does survive is published as an inventory, and it runs to seven records.
• What arrives by way of legal process is counted in the transparency report, and what a valid order actually produces is written down in advance rather than decided in the moment.
• On a VPS or a dedicated server, the logs described on this page are inside your operating system. We do not read them, we do not ship them anywhere, and we also cannot configure them for you — single tenancy cuts both ways, which is the point of it.
• What we can carry is the layer underneath: no identity record at signup, settlement on-chain only, and a machine in a jurisdiction you picked rather than the one your card issuer lives in.

And the sentence the page exists for: choosing a host by what it refuses to keep, then keeping a fortnight of the same thing yourself, is a privacy decision cancelled by a configuration file. The two halves are not comparable in effort. One took a week of reading and the other takes an afternoon, and only one of them is finished.

A one-hour audit of your own logs

Nothing below needs a tool you have to buy, and each step tells you something the step before it did not.

1. Print a single line of your own access log and read it as a stranger would, field by field, out loud.
2. List every file under your log directory, then mark the ones you have opened in the past year. The unmarked ones are pure liability.
3. Read the rotation configuration and write down the number of days it actually keeps, rather than the number you remember agreeing to.
4. Restore last month’s backup into a scratch directory and look for the log you believe was deleted a fortnight ago.
5. Search your access log for the words token, reset, key, session and password. Anything you find is a secret that has already been written to disk and needs rotating, not just fixing.
6. Load your own home page with the browser network panel open and write down every domain contacted that is not yours. Each is a company holding your readers under its own retention.
7. Check which header carries the real address behind your proxy or CDN, and confirm whether the origin writes it down. A CDN does not stop the origin logging; it moves the field.
8. Open the most recent event in your error tracker and count how many details of a real reader are in the payload.
9. Decide three retention numbers on purpose — security, analytics, backups — and write them where the next person to touch the server will find them.
10. Write the inventory: what exists, where, for how long, and what you would produce if a valid order arrived tomorrow morning. If that document is uncomfortable to write, it is the most useful hour on this list.

Questions people actually ask

Every price on this estate is published in full, in one place. See the whole catalogue