saturn

This dataset contains 502 API request logs across 11 columns, capturing usage telemetry like response time, status code, endpoint, and user agent. Traffic is dominated by a single API ('linguistic-api' at 99.6%) and a single method (GET), with all requests coming from one IP (127.0.0.1), so the interesting variation lives in endpoint, response_time_ms, status_code, and user_agent. Response times are heavily skewed: the median is just 3ms but the mean is 163ms with a max of 1238ms and 78 outliers (~24%), plus a 34% null rate worth investigating. Status codes split between 200 and 429, hinting at rate-limiting behavior. The endpoint column has a long tail of 209 distinct paths, with /api/languages and /api/search leading.

A monotonic surrogate key: 502 unique values across 502 rows with no nulls, ranging from 1 to 502 and a perfectly symmetric mean and median of 251.5. Skew is 0.0 and there are no outliers, consistent with a sequential row identifier rather than a measured quantity.

The column 'key_id' was skipped by the profiler, so no type, uniqueness, or distributional statistics are available beyond a row count of 502 and a null rate of 0.0. The name suggests an identifier, but without n_unique or sample values this cannot be confirmed from the evidence.

This is a categorical API identifier with only 2 distinct values across 502 rows. It is overwhelmingly dominated by 'linguistic-api' (500 rows, 99.6%), with 'blissAPI' appearing just twice, yielding near-zero entropy (0.037). The column is effectively a constant with two anomalous records.

This column records API endpoint paths, with 209 unique routes across 502 requests and no nulls. Traffic is spread fairly evenly (entropy ratio 0.828), though /api/languages leads at 11.6% of hits, followed by /api/search (36) and /api/stats (24); a long tail of rarely-hit routes triggers the alert. Notably /api/languages/NOPE appears 11 times, suggesting either a probing client or a broken reference worth investigating.

This column records the HTTP method, but every one of the 502 rows is "GET" — cardinality is 1 and entropy is 0. It carries no information for any downstream model or segmentation.

This column holds HTTP status codes, taking only 2 distinct values across 502 rows: 200 (success) and 429 (rate-limited), with 200 as the median and 429 as Q3. The mean of 278.9 implies roughly a third of requests were throttled, which is a notable failure rate worth investigating. No nulls or outliers, and the bimodal shape is reflected in the negative kurtosis (-1.57).

This column captures response times in milliseconds for 502 records. The distribution is severely right-skewed (skew 1.90, kurtosis 1.74): the median is just 3 ms and Q3 is 21 ms, yet the mean is 162.84 ms and the max reaches 1238 ms, with std at 345.34. Two analyst-relevant flags: 34.46% of rows are null, and 23.71% (78 values) fall outside the IQR fence.

This is a numeric flag named cache_hit, presumably a 0/1 indicator of whether a cache lookup succeeded. Across all 502 rows it is constant at 0 (zero_rate 1.0, n_unique 1, std 0.0), meaning no cache hit was ever recorded. That is either a broken instrumentation path or a workload where caching is disabled.

This column records an IP address but holds the loopback value 127.0.0.1 for all 502 rows, with zero nulls and cardinality of 1. Entropy is 0.0, so the field carries no information and looks like a placeholder or a logging artefact rather than a real client IP.

HTTP User-Agent strings from request logs, with only 12 distinct values across 502 rows and no nulls. Traffic is dominated by non-browser clients: Werkzeug/3.1.4 (the Flask dev server's default UA) at 215 hits and GoogleOther at 196, together covering ~82% of requests, with curl and assorted bots (Bytespider, Applebot, Googlebot, bingbot, GPTBot) making up most of the rest. Genuine human browser traffic appears negligible — only a single Firefox hit and a handful of mobile Safari/Chrome entries.

This is a timestamp column stored as strings, with 299 unique values across 502 rows and no nulls. The distribution is unusually clumpy for a timestamp: six values on 2026-04-17 each repeat 14-38 times, accounting for roughly 189 rows, while most other timestamps appear only a handful of times. That burst pattern suggests batched events or a logging artifact rather than free-flowing event time.