Download Sample Log Files

Sample log files are placeholder datasets used whenever you need realistic log data without running a real server. The most common use cases are testing log parsers and regex patterns, developing Grok/Logstash/Fluentd pipeline configurations before connecting to production, building alerting rules and verifying they fire on the right patterns, stress-testing log ingestion systems (Splunk, Datadog, Elasticsearch) with known volumes, and providing example fixtures in documentation or runbooks.

The Error Pattern fixtures are especially useful: they let you verify that your alerting rules detect 404 spikes, 500 bursts, or login brute-force attempts without waiting for those events to happen organically in production.

Combined Log Format is the de-facto standard for web server access logs. Each line contains: the client IP, a dash (unused ident), the authenticated user (or dash), the timestamp in brackets, the HTTP request line in double quotes, the status code, the response size in bytes, the referer URL in double quotes, and the user-agent string in double quotes. It extends the Common Log Format by adding referer and user-agent. Nginx's default access log also uses this format (with minor differences), which is why parsers written for Apache logs usually handle Nginx files without modification.

Regular JSON would put all log entries in a single array [{...},{...}], which requires loading the entire file into memory before parsing can begin. NDJSON (Newline-Delimited JSON) puts one complete JSON object on each line, with no commas between objects and no wrapping array. This makes streaming parsing trivial — you read one line, parse it, process it, discard it, repeat. Every major log pipeline (Logstash, Fluentd, Vector, Promtail) expects structured logs in NDJSON format, and it's also the format used by Docker's json-file logging driver and many cloud logging APIs.

W3C Extended Log Format is the default format used by IIS (Internet Information Services) and some CDNs. It differs from Apache/Nginx logs in a few important ways: it always starts with comment lines beginning with # that declare the format version, the date the file was generated, and a #Fields: line listing the column names in order. The actual data is tab-separated. The date and time are split into two separate columns rather than combined. This header block is what makes W3C parsers incompatible with Apache parsers even though the underlying data is similar.

A traffic burst in these files is a concentrated spike — roughly 10x the normal request rate — inserted into the middle of the log. In real production environments, bursts happen during product launches, viral content, DDoS attempts, or bot crawls. Log ingestion systems that work fine at steady-state traffic sometimes drop lines, fall behind, or OOM-crash under sudden high volume. Enabling the traffic burst option lets you verify that your pipeline handles rate spikes without data loss, that your alerting thresholds are set correctly, and that your log rotation / retention policies behave under load.

Download the format that matches your target parser. For Apache Combined, the standard Grok pattern is %{COMBINEDAPACHELOG}. For Nginx (same format), use the same pattern. For syslog, use %{SYSLOG5424PRI}%{SYSLOG5424SD} or the built-in syslog codec. For JSON logs, skip Grok entirely and use the json codec or filter. For W3C/IIS logs, the iis Logstash plugin handles the #Fields: header automatically. After downloading, drop the file in your Logstash input { file { path } } or use filebeat to ship it — the file will behave identically to a real log file from a live server.

Yes. IP addresses are drawn from realistic public ranges (not just sequential or obviously fake ranges like 1.2.3.4). User-agent strings cover a mix of real browser versions (Chrome, Firefox, Safari, Edge on Windows and macOS), mobile browsers (Chrome on Android, Safari on iOS), and common bot crawlers (Googlebot, Bingbot, curl). The bot traffic option adds dedicated crawler sessions with the correct bot user-agent strings and crawl patterns. IPv6 addresses, when enabled, use the 2001:db8:: documentation prefix per RFC 3849, which makes them recognizable as sample data while still being syntactically valid and parseable.

CloudFront access logs record every request served by Amazon CloudFront CDN. They are delivered as gzipped tab-separated files to S3 and are commonly analyzed via Athena, Redshift Spectrum, or Elasticsearch. The format starts with two comment lines — #Version: 1.0 and a #Fields: line listing 33 columns — followed by tab-delimited data rows. The sample files here match the exact field order and types that CloudFront produces, making them suitable for testing Athena CREATE TABLE schemas, Glue crawler configurations, and any log analysis tool that needs to be pointed at a CloudFront log before you have real CDN traffic to work with.