Server Logs as Evidence

What a server access log is and what one line records

A web server access log is the file in which the software that serves a website (Apache HTTP Server, Microsoft IIS, Nginx, and others) writes one line for every request it receives. It is the website owner's own record of what was asked for, when, by which address, and what the server sent back. The format directive (the configuration line that tells the server which fields to write and in what order) decides what each line contains, so the first question about any produced log is which format produced it.

The Apache documentation's example of the Common Log Format is the clearest teaching tool: 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326. Reading left to right, the fields are the IP address of the client (the numeric address of the machine that made the request), an identity field that is almost always a hyphen because the information is not available, the user ID if the page required HTTP authentication, “the time that the request was received,” the request line (the method and the URL, the address of the resource requested), the status code (the three-digit number the server sends back, such as 200 for success, 301 for a permanent redirect, or 404 for not found), and “the size of the object returned to the client.” The Apache log documentation defines each one.

The Combined Log Format adds two fields: the Referer header, which “gives the site that the client reports having been referred from,” and the User-Agent header, “the identifying information that the client browser reports about itself.” Microsoft IIS and several content delivery networks instead use the field names of the W3C Extended Log File Format, a 1996 Working Draft from the World Wide Web Consortium (W3C, the standards body for the web) that never became a Recommendation but whose prefixes (c-ip, cs- for client to server, sc- for server to client) remain in use.

Fields the server observed versus fields the client reported

Apache's wording draws a line that matters more than any rule of evidence. The timestamp, the status code, and the bytes sent are things the server itself did or observed. The referrer and the user agent are strings the client “reports,” and any client can send any string. Even the IP address carries a caveat from Apache: it “is not necessarily the address of the machine at which the user is sitting,” because a proxy between the user and the server will appear as the proxy's address.

This is the foundation for cross-examining a log-based claim of “traffic from Google.” A referrer of google.com is the client's statement about where it came from; a user agent of Googlebot is the client's statement about what it is. Neither is evidence that the statement is true. A log line is partly a machine-stamped record and partly a relay of whatever the client sent. In my experience the strongest log opinions say explicitly which fields are server observations and which are client claims, and treat the second category as something to be verified rather than counted.

Rotation: how much history exists before anyone asks

Logs do not keep themselves. Apache's documentation states that “on even a moderately busy server, log files grow quickly — the access log typically grows 1 MB or more per 10,000 requests,” and tells administrators to “set up automatic log rotation from the start.” Rotation (closing the current file, moving it aside, and starting a new one on a schedule) is normally handled by the logrotate utility, which “allows automatic rotation, compression, removal, and mailing of log files” and is “run as a daily cron job.”

The defaults are the point. logrotate's rotate directive sets how many old files are kept before being removed, and its manual states the default is 0, meaning “old versions are removed rather than rotated.” On Debian and Ubuntu, the Apache package ships a configuration that rotates /var/log/apache2/*.log daily and keeps 14 copies. In practical terms, a stock install of the most common Linux web server holds roughly two weeks of access history unless someone changed the file. That sits at the low end of the examples in NIST SP 800-92 Table 4-1, which gives one to two weeks for low-impact systems, and it is the condition that led the ACSC and CISA to state in 2024 that default log retention periods are often insufficient.

The consequence is arithmetic. If the conduct at issue occurred more than two weeks before a preservation letter arrived, the origin log for that period exists only if the host changed the rotation count, shipped logs elsewhere, or kept backups. Ask for the rotation configuration file itself; it is one line of evidence that explains the absence of everything else.

What a CDN changes: Cloudflare as the example

A content delivery network (a CDN, a network of servers that sits in front of a website and answers requests on its behalf) rewrites the picture. Cloudflare's documentation explains that when traffic is routed through its network, Cloudflare acts as a reverse proxy, and “as a result, when responding to requests and logging them, your origin server returns a Cloudflare IP address.” The visitor's real address “appears in an appended HTTP header called CF-Connecting-IP.” Unless the origin server was configured to log that header in place of the client address, the origin log of a Cloudflare-fronted site records Cloudflare's addresses for every request. The log is authentic. It just does not show what an unprepared reader assumes.

Cloudflare's own request log carries fields the origin never sees: the client IP, the requested host and URI, the user agent and referrer, the status Cloudflare returned to the client and, separately, the status the origin returned, the cache status, a Ray ID identifying the request, and for Bot Management customers a BotScore, where “scores below 30 are commonly associated with automated traffic,” together with a verified-bot category. The edge log can therefore show requests the origin never received, including cache hits and blocked requests.

Retention is the catch. Cloudflare states that “by default, your HTTP request logs are not retained,” that once enabled logs are available “for at least three days and up to seven days,” and that for longer periods the customer should “download and store them locally” or use Logpush, which pushes logs to the customer's own storage or log management provider. A preservation letter to a Cloudflare-fronted site that arrives eight days after the relevant traffic is already too late for CDN logs unless Logpush was running. Cloudflare's current pages do not restrict these features to a particular plan, and no plan restriction should be asserted without a current page.

Separating bots from humans, and verifying Googlebot

Because the user agent is a client claim, a log analysis that counts “Googlebot” requests has counted assertions. Google publishes the method for checking them. For one-off lookups, run a reverse DNS lookup (a query that returns the host name registered for an IP address) on the address from the log, confirm the domain is googlebot.com, google.com, or googleusercontent.com, then run a forward lookup on that host name and confirm it resolves back to the same address. Google's example: host 66.249.66.1 returns crawl-66-249-66-1.googlebot.com, and host crawl-66-249-66-1.googlebot.com returns 66.249.66.1. For large-scale work, Google publishes JSON lists of crawler IP ranges in CIDR notation, separated into common crawlers such as Googlebot, special-case crawlers such as AdsBot, and user-triggered fetchers that ignore robots.txt. The procedure is on Google Search Central.

An expert separating bot from human traffic should document the verification method, the date or version of the IP list used, and the fraction of self-declared Googlebot requests that failed verification. That last number is often the most revealing figure in the analysis. A CDN bot score is a vendor classification, not a DNS verification, and the two should not be presented as equivalent.

Authentication: Rule 901(b)(9) and the certification route

Rule 901(a) requires “evidence sufficient to support a finding that the item is what the proponent claims it is.” For logs the natural illustration is 901(b)(9): “Evidence describing a process or system and showing that it produces an accurate result.” The Advisory Committee Note explains that the example “is designed for situations in which the accuracy of a result is dependent upon a process or system which produces it,” names the computer among those situations, and adds that it “does not, of course, foreclose taking judicial notice of the accuracy of the process or system.”

Since December 1, 2017, that showing can be made on paper. Rule 902(13) covers “a record generated by an electronic process or system that produces an accurate result, as shown by a certification of a qualified person” that complies with 902(11) or (12), and 902(14) covers “data copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification.” The Committee Note to (14) explains that such data “are ordinarily authenticated by ‘hash value,’” a number produced by an algorithm from the file's contents, and that identical hash values for original and copy “reliably attest to the fact that they are exact duplicates.” For a log production the two certifications map cleanly: the hosting administrator certifies under (13) that the server's logging process records each request and produces an accurate result, and the person who copied the files certifies under (14) that the hash of the copy matches the original. Both carry 902(11)'s requirement of reasonable written notice to the adverse party before trial. The rule text is at Cornell LII.

The Committee Note sets the limits in terms worth quoting back to a proponent. A 902(13) certification “can establish only that the proffered item has satisfied the admissibility requirements for authenticity,” a certification of a computer output “does not preclude an objection that the information produced is unreliable,” and “any attempt to satisfy a hearsay exception must be made independently.” The Note also anticipates that a challenge “may require technical information about the system or process at issue, including possibly retaining a forensic technical expert.” Rotation settings, the format directive in force, and whether the produced file was regenerated from a CDN export are all system facts that belong in that challenge.

Hearsay: the computer-generated-record line and the 803(6) alternative

Rule 801 defines a statement as “a person's oral assertion, written assertion, or nonverbal conduct, if the person intended it as an assertion,” and a declarant as “the person who made the statement.” The closest appellate analogue for a log is United States v. Hamilton, No. 04-4091 (10th Cir. June 29, 2005), where the Tenth Circuit considered header information, including an IP address and the date and time of upload, that “was automatically generated by the computer hosting the newsgroup” and “generated instantaneously by the computer without the assistance or input of a person,” and concluded “there was neither a ‘statement’ nor a ‘declarant’ involved here within the meaning of Rule 801.” An access-log line's server-stamped fields are the same kind of record.

United States v. Lizarraga-Tirado, No. 13-10530 (9th Cir. June 18, 2015), supplies the rest of the framework: an automatically generated label “isn't hearsay,” but “a machine might malfunction, produce inconsistent results or have been tampered with,” and “such concerns are addressed by the rules of authentication, not hearsay,” specifically Rule 901(b)(9). Lorraine v. Markel American Insurance Co., 241 F.R.D. 534 (D. Md. 2007), a magistrate judge's persuasive opinion that predates the 2017 certification rules, reasoned the same way about a fax transmission report and set out the eleven-step business-record foundation for computer records while noting that courts disagree on how demanding it should be. No reported decision squarely ruling on an Apache or IIS access log under 901(b)(9) or 902(13) was located; these are analogues, not log cases, and should be presented that way.

Proponents often offer logs under Rule 803(6) as well, which requires that the record was made at or near the time by someone with knowledge, kept in the course of a regularly conducted activity, as a regular practice, shown by a custodian or a 902(11) certification, and not shown by the opponent to be untrustworthy. The non-hearsay route avoids the someone-with-knowledge problem for machine-stamped fields; the 803(6) route stays open to a trustworthiness challenge where logs were rotated, edited, or reconstructed. The two routes are not mutually exclusive, and neither makes a client-supplied referrer or user agent evidence that its contents are true.

Frequently Asked Questions

Published 2026-11-04