randarium
Developer Data

Log Generator

Create realistic-looking log lines for parser, monitoring, and observability demos. All entries are synthetic.

Also known as: mock logs · access log generator

seeded · synthetic data

Output

No output yet — set your options and hit .
About this tool, tips & examples

What it does

The Log Generator produces realistic, clearly synthetic application log lines — up to 10,000 per run — with your service name, a configurable mix of log levels, and optional stack traces on error entries. Export as plain text or NDJSON, and reuse the seed to regenerate the identical log file for every test run.

Common use cases

  • Parser and pipeline tests — grok patterns, regex extractors, and log shippers verified against a stable fixture file.
  • Observability demos — populate Loki/Elasticsearch/CloudWatch-style tooling with data safe to show anyone.
  • Alert-rule development — a controlled error-rate mix for testing level-based alerting thresholds.
  • Log-viewer UIs — realistic content for testing filtering, highlighting, and stack-trace folding.

Settings

  • Lines — 1 to 10,000 log entries.
  • Service — the service name stamped on each line.
  • Level mix — the distribution across debug/info/warn/error.
  • Include stack traces — attach multi-line traces to error entries, the case that breaks naive line-by-line parsers.
  • Seed — identical seed + settings = identical log file.

Privacy note

Logs are generated locally in your browser and never uploaded. Every entry is synthetic — fabricated messages, IDs, and traces — so nothing sensitive can leak through a demo or fixture, unlike scrubbed production logs, which always leak something.

FAQ

Why not just use real production logs? Because they’re radioactive: IPs, IDs, tokens, and PII hide in messages even after scrubbing. Synthetic logs have the same shape with zero disclosure risk.

Why do stack traces matter for testing? They’re multi-line events. Any parser that assumes one-line-per-entry shreds them into garbage — better to find that out from a fixture.

Text or NDJSON? NDJSON if your pipeline speaks structured logs; plain text to exercise the parsing path itself.