Skip to content

Example data

Example logs for trying anytimeline without data of your own; the same seed gives the same data.

service_log

service_log(
    requests: int = 2000,
    *,
    seed: int = 0,
    start: str = "2026-10-12T08:00:00",
) -> dict[str, ndarray]

A log of web requests passing through services: one row per event.

Each request arrives at the gateway, is authorised, handled by the API (with a database query or a cache hit) and answered. About 3% fail somewhere along the way. Requests arrive over about an hour with a burst in the middle; times have microsecond precision.

Returns:

  • dict[str, ndarray] –

    Columns time (datetime64[us]), service, event, level

  • dict[str, ndarray] –

    ("info", "warning", "error"), request ("r0001", ...), user,

  • dict[str, ndarray] –

    bytes and seq (the order in which the log wrote the events).

instants

instants(
    n: int = 100000, *, lanes: int = 20, seed: int = 0
) -> dict[str, ndarray]

Many events on many lanes, for performance tests: time (datetime64[ns] over a day), lane, kind (8 categories) and value.

traces

traces(
    n: int = 12,
    *,
    seed: int = 0,
    start: str = "2026-10-12T08:00:00",
    error_rate: float = 0.15,
) -> Traces

Traces of web requests through services: spans under spans, as an OpenTelemetry exporter would give them (the columns of read_otlp).

Three kinds of request: GET /orders (auth, a cache, database queries and a fan-out to the inventory service in parallel), POST /checkout (a transaction around a slow payment) and GET /search (shards queried in parallel). Some fail: a query times out, is retried, and the error is recorded as an exception event. Requests start a few seconds apart and may overlap; times have microsecond precision.

Returns:

  • Traces –

    spans (trace_id, span_id, parent_id, name, service,

  • Traces –

    kind, status, start, end) and events (trace_id, span_id,

  • Traces –

    time, name, attributes).

service_metrics

service_metrics(
    requests: int = 2000,
    *,
    seed: int = 0,
    start: str = "2026-10-12T08:00:00",
    step_s: float = 10.0,
) -> dict[str, ndarray]

Metrics of the services in service_log (same requests, seed and start): a sample per service every step_s seconds, from the log's load, so the burst of requests shows in them.

Returns:

  • dict[str, ndarray] –

    Columns time (datetime64[ms]), service, rate (events per second),

  • dict[str, ndarray] –

    cpu (%), queue (requests waiting), p50_ms and p99_ms (latency).

service_health

service_health(
    requests: int = 2000,
    *,
    seed: int = 0,
    start: str = "2026-10-12T08:00:00",
) -> dict[str, ndarray]

The health of the services in service_log as changes of state: "up", "degraded" (while the CPU is above 75%) and "down" (the cache, for two minutes, restarting after the burst). A row per change, with the reason.

Returns:

  • dict[str, ndarray] –

    Columns time (datetime64[ms]), service, state and reason.

incident

incident(
    *, start: str = "2026-10-12T14:00:00"
) -> dict[str, ndarray]

What happened during an incident, as a postmortem's timeline lists it: a bad deploy, the alerts, the people paged, the rollback and the recovery, about two hours of events.

Returns:

  • dict[str, ndarray] –

    Columns time (datetime64[s]), title, kind ("deploy", "alert",

  • dict[str, ndarray] –

    "page", "action", "status"), team and importance (1 to 3).