Sensor, market, event, and telemetry series with documented intervals, gaps, duplicates, and timezone behavior for testing importers, resampling, charts, and anomaly pipelines.
A year of daily OHLCV stock candles (open/high/low/close/volume) as a seeded random walk — a realistic finance time-series for testing charting, indicators, and importers. JSON twin included.
The daily OHLCV candles as a JSON array — the format twin of the CSV, for charting and time-series testing.
A day of IoT sensor readings (temperature, humidity, pressure) at one-minute intervals from three sensors, with a realistic daily cycle plus noise — for testing time-series ingestion and downsampling. JSON twin included.
The IoT sensor readings as a JSON array — the format twin of the CSV, for time-series testing.
A 30-day daily weather forecast for one city — high/low temperature, condition, precipitation, wind, and humidity. Synthetic (seeded) data for testing weather widgets, chart tools, and time-series import.
The daily forecast as a JSON array — the format twin of the CSV, for import and charting tests.
An ROC curve as CSV — decision threshold with the corresponding false-positive and true-positive rates, monotonic from (0,0) to (1,1). A fixture for testing chart tools and AUC calculators.
Forty builds of six tests, one JSON object per line, with three tests that fail intermittently and three that never do. This is the input shape a flake detector ingests; the CSV twin in this group holds the aggregate it should produce.
The aggregate answer key for the 40-build history in this group: runs, passes, failures and failure rate per test, with each test labelled stable or flaky. Use it to score a detector rather than eyeballing 240 JSONL records.
Three hundred individual request records with timestamp, scenario, status and duration — the raw log a percentile calculation has to be computed from rather than read off. A handful of 4xx and 5xx responses are mixed in so an error-rate calculation has something to find.
The body a /metrics endpoint returns: five metric families with HELP and TYPE metadata across 27 labelled series — request counters by route and status, process and runtime gauges, per-target up values (one deliberately 0) and a business gauge. The baseline exposition-parser fixture.
A classic Prometheus histogram: eleven finite le buckets plus +Inf, with monotonically non-decreasing cumulative counts and matching _sum and _count series. The fixture for bucket ordering, cumulative arithmetic and histogram_quantile interpolation.
Two summary families — one exposing four client-side quantiles including quantile="1" for the observed maximum, and one exposing only _sum and _count, which is legal and common. Summaries cannot be re-aggregated across instances, and this fixture is where that gets tested.
Every numeric form the exposition format permits: NaN, +Inf and -Inf, negative zero, denormal and maximum doubles, and a uint64 counter beyond the exact range of a double. Parsers that route values through a JSON number or a 32-bit float fail on this file specifically.
Samples with explicit millisecond timestamps alongside samples without any, including one an hour stale and one an hour in the future. Optional timestamps are the part of the exposition format most parsers get wrong, and out-of-window samples are what a scraper must reject rather than backfill.
A single metric family blown up to 2,000 series by two unbounded labels — customer_id and session_id — which is the most common way a metrics bill and a TSDB both fall over. A load fixture for scrape parsing and a worked example for cardinality-limit rules.
The file a cron job drops into the node_exporter textfile directory so a batch task can be monitored without a scrape endpoint: last-success timestamp, artefact size, duration and per-job exit codes, one of which is non-zero. The canonical shape for batch-job alerting.
A complete OpenMetrics document — the _total and _created series a counter really has, UNIT metadata, an info metric carrying build metadata and a stateset with exactly one active state — terminated by the mandatory # EOF. This is what the exposition format became once it was standardised.
Histogram buckets carrying exemplars whose trace_id and span_id resolve against the OTLP trace fixtures in this category — the exact-to-example link that turns a latency spike on a graph into a specific request. Five exemplars, each with its own observed value and timestamp.
An OTLP metrics export with a monotonic cumulative sum and two gauges, showing the parts of the wire format that trip parsers: int data points serialised as JSON strings, UCUM unit annotations like {request} and By, and the start timestamp that makes a counter reset detectable.
Cumulative sums whose start timestamp stays fixed across exports, so every point is the running total since process start. Paired with a delta-temporality twin covering the same window, because converting between the two is a stateful operation that a bridge must get right in both directions.
The same 24 hours of cart updates as six delta points, each with its own start and end timestamp covering a four-hour window. The delta twin of the cumulative fixture: summing these must reproduce the cumulative total exactly, and a gap or overlap in the windows is the failure to catch.
An OTLP histogram carrying two exemplars, each with the trace and span ID of a request that landed in that bucket — including the 2.0031-second outlier that corresponds to the failed payment in the error-trace fixture. The metrics-to-traces jump, with a resolvable target.
A monotonic counter that drops from 94,880 to 1,120 when its process restarts, with startTimeUnixNano changing at exactly that point to mark the reset. Rate calculations that subtract consecutive values without checking the start timestamp produce a large negative rate here.
A Prometheus /api/v1/query_range response: three labelled series of 30 points each at a 60-second step, with sample values as JSON strings and timestamps as float seconds. The exact envelope a dashboard client has to unpack, including the string-typed values that break naive charting code.
The same 90 samples as the query_range response, exported one row per observation with both epoch and ISO 8601 timestamps. The long layout every dataframe library prefers, and half of a reshaping pair.
The same 90 samples pivoted to one column per service and one row per timestamp — the layout a spreadsheet chart expects. Paired with the long-format export so a reshape can be scored in both directions.
Five recording rules following the level:metric:operation naming convention, where one rule consumes two others recorded earlier in the same group — evaluation order inside a group is sequential, which is exactly what makes that legal and what a rule validator must understand.
A day-by-day burndown of the availability SLO defined in the OpenSLO fixture: achieved ratio, budget consumed and remaining, and one-hour and six-hour burn rates. Consumption is monotonic across the window, which is the invariant a burn-rate chart must not violate.
The baseline GPS trace for this category: 24 timestamped, elevated trackpoints in a single segment, walking the Coast Road of the invented territory. Every other GPX fixture here is this file with one thing changed.
The same 24 points split into two `trkseg` elements with a ten-minute gap between them — what a receiver writes after a stop or a signal loss. Tools that concatenate segments without noticing the boundary report a moving average dragged down by a pause that never happened on the move.
Eight trackpoints with timestamps but no `ele` element, the shape a receiver writes on a 2D fix. Elevation-profile code that assumes the element is present either crashes or charts a flat line at zero, which looks like real data.
The same eight points with elevation but no `time` element — what you get when a track is drawn in a planning tool rather than recorded. Speed and pace calculations must refuse to produce a number here instead of dividing by a zero duration.
Eight trackpoints each carrying a Garmin TrackPointExtension with heart rate, cadence and air temperature. The GPX schema deliberately leaves `extensions` open, so this is the fixture for checking that a reader surfaces vendor data instead of discarding it on export.
The same eight points timestamped with a +01:00 offset rather than the usual Z. The digits are identical to the reference track, so a parser that strips the offset and assumes UTC produces times that are wrong by exactly one hour — a silent error that only shows up when two traces are merged.
A track containing exactly one point, which is what a receiver writes when a recording is stopped immediately. Distance, speed and bearing all need a pair of points, so this is the fixture that finds off-by-one loops and empty-slice crashes.
Seven trackpoints whose timestamps go forwards, backwards, and then repeat — the pattern a receiver produces after a clock correction or a buffered replay. Naive speed calculations divide by a negative or zero time delta and emit impossible values.
A twelve-fix receiver log with the five sentence types a GPS unit normally interleaves, including three-part GSV satellite-in-view sets. Every checksum is correct, so a parser that verifies them should accept the whole file.
The same twelve fixes reduced to GGA alone. GGA carries time-of-day but no date and no speed, so a parser that only reads GGA cannot place the track on a calendar — a real limitation that this file makes obvious rather than leaving to be discovered later.
Four Placemarks with a `TimeSpan` and one with an instantaneous `TimeStamp`, which is what drives the time slider in a globe viewer. Time is the first thing a KML-to-GeoJSON conversion drops, because RFC 7946 has no place to put it.
A `gx:Track` from the Google KML extension: ten `when` timestamps followed by ten `gx:coord` positions, paired by index rather than nested. Note the coordinates are space-separated here even though core KML uses commas — a detail that breaks parsers reusing the same splitting code.
Five timestamps stored as datetime64 with second resolution, where the unit is part of the dtype descriptor and the values on disk are plain int64 epoch seconds. Dropping the unit turns 2026-01-01 into the integer 1767225600 without any complaint.
A full day of thermocouple readings at 30-minute cadence with a constant type-B standard uncertainty and two rows flagged as recovering. The timestamps are explicit UTC with a Z suffix so a reader has no excuse to guess a timezone.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
