What fields does each log entry contain?

Every row carries a timestamp, a device id, the sensor name, the numeric value, the unit, and a status of OK or ALERT. That mirrors the typical shape of an IoT telemetry record so your parser sees realistic columns.

How are alert readings created?

For the share you set as the fault rate, the tool deliberately pushes the value below the minimum or above the maximum of the sensor's normal band and stamps the row ALERT. This lets you verify that thresholds, alarms, and anomaly detectors actually fire.

What is NDJSON and why use it?

NDJSON is newline-delimited JSON, one complete JSON object per line. Log shippers, message queues, and streaming consumers expect this format because they can read and process one record at a time without parsing a whole array.

How are timestamps spaced?

The newest entry is stamped at the current time and earlier entries step backward by the sampling interval you choose, written in ISO 8601 UTC. This produces an ordered log that looks like it was collected over a real window.

Does anything leave my browser?

No. All readings are generated locally with no network calls, so you can produce large synthetic logs privately and offline.

What is the Fake Sensor Log Generator?

Generate fake sensor log entries in CSV or NDJSON with timestamps, device IDs, readings, units, and a configurable share of out-of-range ALERT rows. Useful for testing IoT data pipelines, log parsers, and anomaly-detection logic. It runs free in your browser on Gera Tools, with nothing uploaded.

Fake Sensor Log Generator

Name: Fake Sensor Log Generator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

This tool generates fake IoT sensor logs — rows of timestamped readings with device IDs, units, and status flags — so you can test data pipelines, log parsers, and alerting rules without wiring up real hardware. A configurable fraction of readings are deliberately pushed out of range and marked ALERT, giving you anomalies to detect.

How it works

Each sensor type has a realistic normal band, for example temperature 18 to 26 degrees C or CO2 400 to 1200 ppm. For each entry the tool decides whether it is a fault based on your fault-rate percentage:

A normal reading is drawn uniformly from inside the sensor’s band and stamped OK.
A fault reading is pushed below the minimum or above the maximum and stamped ALERT.
The entry gets a rotating device id, the sensor name, the value, the unit, and an ISO 8601 timestamp.

Entries are spaced by your chosen interval with the most recent reading last, then rendered as CSV with a header row or as NDJSON with one object per line.

Sensor normal ranges

Sensor	Normal band	Unit
Temperature	18–26	°C
Humidity	30–70	% RH
Pressure	950–1050	hPa
CO2	400–1200	ppm
Vibration	0–5	mm/s

Readings within these bands are labelled OK. A fault reading is pushed deliberately outside — for example, a temperature fault might be 35°C or 5°C, clearly outside the normal band. This distinction is important because real anomaly-detection systems typically compare each reading against a threshold, not just a flag.

Output format comparison

CSV format includes a header row and is easiest to open in a spreadsheet or import into a database. A sample row looks like:

timestamp,device_id,sensor,value,unit,status
2026-06-15T09:00:00Z,device-03,temperature,22.4,°C,OK
2026-06-15T09:05:00Z,device-07,co2,1350,ppm,ALERT

NDJSON (newline-delimited JSON) writes one complete JSON object per line, which is what streaming log shippers, Kafka consumers, and time-series ingestion APIs typically expect:

{"timestamp":"2026-06-15T09:00:00Z","device_id":"device-03","sensor":"temperature","value":22.4,"unit":"°C","status":"OK"}
{"timestamp":"2026-06-15T09:05:00Z","device_id":"device-07","sensor":"co2","value":1350,"unit":"ppm","status":"ALERT"}

Practical use cases

Alerting rule testing: set the fault rate high (for example 30%) to ensure your alerting system fires reliably and does not silently drop ALERT rows under load.
Time-series visualization: generate a 200-point temperature series with 5% faults and feed it into a Grafana, Recharts, or Chart.js panel to verify alert annotations display correctly.
Log-ingestion pipeline: use NDJSON to exercise a Logstash, Fluentd, or Vector pipeline end-to-end without waiting for real device data.
Anomaly-detection algorithm: mix 2% faults into a 500-row dataset and measure whether your detection logic identifies the right rows.

Tips and notes

Set the fault rate to a few percent to mimic occasional glitches, or higher to stress-test alert handling.
CSV is easiest for spreadsheets and quick eyeballing; NDJSON is what most log-ingestion and streaming systems expect.
The device id cycles through eight simulated devices, so you can test per-device grouping, filtering, and device-level alert aggregation.