v1.6.0

Fixed

GET /metrics answered HTTP 500 under RegisterDashboardHandlers and 404 under Fiber, while the same path answered 200 under RegisterAPIHandlers. Prometheus marks a target down on a 500, so anyone mounting the dashboard through the unified handler had a scrape endpoint that looked dead. The endpoint is served at the root rather than beneath the API base path, and the unified handlers dispatched to the API only on that prefix.

A window predating service start returned HTTP 500 — which is every fresh install asking for a 24h range. Both read endpoints clamp the requested start up to the service start time, so a window ending before startup became start > end. The dashboard reads a failed series fetch as a lost connection, so a healthy service reported itself as having stopped answering.

Also fixed:

• The API surface was declared separately in five registration sites, which is how the /metrics drift happened. It is now declared once in routes.go, and a test drives every route through every registration style.
• The two storage backends disagreed about an empty result: tstorage returned an error where the in-memory backend returned an empty slice. Both now answer (nil, nil).
• pprof.StartCPUProfile's error was discarded. CPU profiling is a process-wide singleton, so a second traced call sampled concurrently got "already in use", the error vanished, and the caller recorded a profile path pointing at a zero-byte file.
• The Reports range control offered a 5m button its renderer had no entry for; clicking it threw out of the handler and silently stopped the page.
• The runtime chart never refreshed while LIVE was on, and the "not enough history" message hardcoded a 5m sync interval regardless of configuration.
• tstorage data from a test run was committed, so running the suite modified a tracked file.

Added

Per-function call counts and approximate latency percentiles — CALLS, P50 and P95 on the Functions table. The distribution comes from a fixed-bucket histogram: 216 bytes per function regardless of call volume, against ~10 MB at the function cap for keeping raw samples. Values are bucket upper bounds rather than interpolations, shown as ~4ms meaning "at most 4ms". Below 20 calls the columns read —, because p95 of three calls is the slowest of three, not a percentile.

Also in CI

The 13 nested example modules now build on every push. They each carry a replace pointing at the working tree, which makes them the only check that a public API change does not break the code consumers copy from — the root go test ./... never compiled them.

Full changelog: v1.5.0...v1.6.0