Test Event Log Generator

What this generator does

Adds the columns that make a timestamp sequence look like a log. Where the timestamp generator gives you a column of times, this attaches an event name, an actor identifier and an HTTP-style status to each one, weighted so that most requests succeed — which is what stops synthetic logs looking obviously fake and stops charts built on them being dominated by errors.

How to use this tool

1. Set the start time and how many rows you need.
2. Choose the interval between events and add jitter for realism.
3. Press Generate log.
4. Copy the CSV into your fixture, seed script or spreadsheet.

Understanding the controls

Start and how many

The first event's time and the number of rows. Together with the interval these set the period the log covers, which is shown in plain language above the table.

Interval and unit

The nominal gap between events. A busy service might be seconds apart; an audit log might be hours. This is what determines whether your test data looks like traffic or like paperwork.

Jitter

Spreads the gaps so events do not arrive on a metronome. Real events never arrive at exactly equal intervals, and a log that does will not exercise time-bucketing code properly.

Seed

Fixes both the timing and the column values, so a committed fixture regenerates identically. Without one, every run produces a different log.

Worked examples

25 rows, 5 minutes apart, 40% jitter

About two hours of traffic, mostly 200s, with a scattering of 4xx and 5xx.

500 rows, 10 seconds apart

Roughly 83 minutes of dense traffic — enough to make a rolling chart show a real curve.

One row of output

12,user.login,usr_4f2a,200 — sequence number, event, actor, status.

Common use cases

• Seeding a dashboard so charts have something to draw before real traffic exists
• Testing a log viewer's filtering, sorting and pagination
• Demonstrating an analytics feature without exposing real customer data
• Load-checking a table with realistic row shapes rather than repeated placeholders
• Building a fixture for tests that aggregate events by type or status

How this generator works

An ordered timestamp sequence is generated first, then each row is decorated with an event name, an actor and a status drawn from built-in vocabularies. Statuses are deliberately not uniform: a success weighting means roughly four rows in five carry a 2xx code, with errors distributed through the rest. Uniform statuses are the giveaway of generated data and would make any error-rate chart built on the fixture meaningless, so the bias is the point rather than a shortcut.

Randomness and fairness

Three separate draws happen per row — the timing offset, the event and actor, and the status — and only the status draw is weighted. All of them run through a generator that is deterministic, not cryptographic, when a seed is supplied, so a seeded log is byte-identical between runs — which is what makes it safe to assert against in a test, and why none of this output should ever be treated as a source of secure randomness.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

• The event names, actors and statuses come from fixed lists built into the page. You cannot supply your own vocabulary, so the rows will not match your application's real event taxonomy.
• Actors are drawn independently for each row, so there are no sessions, no user journeys and no causal ordering — a logout can appear before the matching login.
• Status codes are unrelated to event names. A payment failure and a search request are equally likely to carry a 500, which real systems do not do.
• There is no request duration, no payload, no IP address and no user agent, so anything testing those fields will need columns added by hand.
• Traffic is flat apart from jitter. There are no daily peaks, no quiet nights and no incident spikes.

Common mistakes

Using the output to test an error-rate alert

Status codes here are unweighted by event and roughly fixed in proportion, so an alert tuned against this data will not behave the same against real traffic.

Expecting user journeys to make sense

Rows are independent, so a single actor's events will not form a coherent session. Generate per-actor sequences separately if journey order matters.

Committing an unseeded log as a test fixture

Set a seed first. Without one the next regeneration produces entirely different rows and any assertion against them breaks.

Practical tips

• Generate a small log first and check the column shape against your schema before producing five hundred rows.
• If you need your own event names, generate the timestamp column here and join your vocabulary onto it in a spreadsheet.

Privacy and your data

Every value in the output is invented in your browser from the page's own built-in lists, so no real user, session or address is involved at any point. Nothing is uploaded and nothing is stored — the log exists only in the tab on your device until you copy it. Actor identifiers look like real ones on purpose, but they are placeholders and correspond to nobody.

Frequently asked questions

Is this real log data?

No. Every value is invented from built-in lists and corresponds to no real person, session or system.

Can I use my own event names?

Not on this page. Use the timestamp sequence generator for the time column and add your own vocabulary alongside it.

Why are most rows successful?

Because real systems mostly succeed. A uniform spread of status codes would make any chart built on the fixture misleading.