Developer tooling · log analysis · browser-local · 2026 · Solo — TDD engine design, sliding-window anomaly detection, donut chart renderer, harness-verified full-stack deployment
Signal Plot
A Monitor-surface log analyzer that turns raw access logs into glanceable operational intelligence — no upload, no account, no API.
The problem
Engineers debugging access logs either squint at raw text or pay for a SaaS log aggregator with a 10-minute delay. There is no decent browser-local analyzer: you paste a few hundred lines into grep and manually count 404 storms. Signal Plot fills that gap. The tool parses nginx and Apache Combined/Common Log Format lines entirely in-browser, groups entries into per-minute buckets, renders a request-rate timeline with an amber error overlay, draws a status-distribution donut ring, ranks top-10 endpoints by request count, and detects three anomaly classes with sliding-window algorithms (404 storm: ≥20 distinct 404 paths from one IP within 60 s; 5xx burst: ≥10 server errors in any 60 s rolling window; scanner: ≥15 distinct paths from one IP within 60 s). The surface archetype is Monitor: dense and glanceable, no hero, no marketing. 26 TDD unit tests cover parseLogLine, classifyStatus, bucketByMinute, topPaths, detectAnomalies, and computeStats — all pure functions verified RED→GREEN before any UI. Harness check-deploy and check-behavior both passed against the live production HTTPS URL. Slop audit: 0/10 (void-black canvas, emerald accent chosen deliberately, no feature-tile grid, no center stack, correct surface).
Architecture
Key decisions
Separate anomaly passes per IP for correctness
The initial implementation ran a single sliding-window pass per IP, checking 404-storm first and advancing the left pointer on a match — which suppressed the scanner check for IPs that triggered the 404 threshold first. A TDD test caught this: 'detects a 404 storm' failed because the scanner check (≥15 paths) fired before the 404-storm check (≥20) could accumulate enough paths. The fix runs two independent passes: one for 404-storm, one for scanner. This is strictly more correct and the test proved it.
Monitor surface over landing page
Log analysis is an operational task: the user is watching state change and needs to act on it. A hero section, feature cards, or a centered CTA would contradict the workflow. The sticky summary bar, dense timeline, and anomaly card feed are the correct composition for a Monitor surface. All slop tells (feature-tile grid, center stack, wrong surface) score 0.
Browser-local with no API tier
Log lines contain IP addresses, paths, and request patterns that may be sensitive. Uploading to a server to parse 200 lines is both unnecessary and a privacy risk. All parsing, bucketing, and anomaly detection run synchronously in the browser. The product is a static Next.js page that can be deployed anywhere — the Vercel deployment is just CDN hosting for the HTML/JS bundle.