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?

Yes — paste them in, along with your own actors and statuses. Tick the coverage box and every one of them is guaranteed to appear at least once.

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.

Test Event Log Generator

Builds rows that look like a real event log: a timestamp, an event name, an actor and a status code, in time order. The event names, actors and statuses are yours — paste in the ones your system actually emits, because a fixture in somebody else's vocabulary exercises somebody else's taxonomy. Useful for filling a dashboard, exercising a log viewer or seeding a table with something more convincing than a hundred identical rows.

Start (UTC)

Read as UTC, so the same inputs give the same output on any machine.

How many

Up to 500 entries.

Interval

The nominal gap between one entry and the next.

Interval unit

Jitter (%)

Varies each gap by up to this much either way. 0 gives a perfectly regular run; capped at 90% so entries can never overtake.

Seed (optional)

A word that makes the log reproducible in a committed fixture.

Event names

One a line, or separated by commas. Yours, not ours.

Actors

User ids, service names, whatever your logs put in that column.

Statuses

The first one is treated as the success case and appears more often.

Use every value at least once

A fixture exists to exercise something, and a log that happens not to contain half your event types exercises half of what you meant it to — which is easy not to notice, because the log looks fine. Tick the box and every value you listed is guaranteed to appear; leave it off and the page tells you afterwards how much of each list was used. Nothing you type here leaves your browser.

Your sequence will appear here.

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

Set the start time and how many rows you need.
Paste your own event names, actors and statuses, one a line — or keep the examples to see the shape.
Tick the box if every value you listed has to appear at least once, which is usually what a fixture is for.
Press Generate log, then 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.
Event names, actors and statuses: Your own, one a line or separated by commas. The first status is treated as the success case and appears more often, because a uniform status column is what gives synthetic logs away. Two spellings that differ only in case are kept apart, since a log search treats them as different strings.
Use every value at least once: Guarantees each value you listed appears somewhere in the log, which is what a fixture usually needs: a log that happens not to contain half your event types exercises half of what you meant it to. If there are more values than rows the page says so with both numbers rather than quietly dropping some. The success weighting is kept: each status is placed once and the rest are drawn as they are without the box.
Seed: Fixes the whole log — the times and the event, actor and status on every row — so a committed fixture regenerates exactly. Without one, every run is different.

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,2026-01-01T09:57:06.201Z,payment.failed,usr_66d2,200 — sequence number, timestamp, event, actor, status. Row 12 from seed round11 at the starting settings.

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 the lists you gave. Statuses are deliberately not uniform: a success weighting means most rows carry the first status you listed, with the rest distributed through the others. 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. Afterwards the finished rows are read back: every value in every column is confirmed to be one you listed, the rows are confirmed to be in order, and where you asked for full coverage every listed value is confirmed to appear. Where you did not ask for it, how much of each list was used is counted and shown rather than promised.

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

Sixty values a column at most, and your lists stay in your browser: there is no link that carries them, so sharing a fixture means sharing the CSV.
Actors are drawn independently for each row, so there are no sessions and no user journeys — a logout can appear before the matching login. Where a request needs its calls to nest inside the one that made them, the distributed trace generator builds that instead.
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, or rows from the synthetic test data generator, whose column list includes IP address and user-agent fields.
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.
Paste the event names straight out of your own code or schema rather than retyping them, so the fixture matches what your system really emits.

Privacy and your data

The lists you paste in are yours and stay in this page: they are never transmitted, never stored, and never written into the address, and what is measured is only that a log was generated and how many rows it had. The rows themselves are assembled in your browser — nothing is uploaded, and the log exists only in the tab on your device until you copy it. Use placeholder identifiers rather than real ones: this page cannot tell the difference, and a fixture is not the place for either.

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?: Yes — paste them in, along with your own actors and statuses. Tick the coverage box and every one of them is guaranteed to appear at least once.
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.