Live telemetry, app fleet, logs, stress lab and a utility belt for this box.
Discovered live from Docker — every app published via the edge proxy shows up here automatically. The ☰ button jumps to that app's logs.
| Container | State | CPU | Memory | Image | Status |
|---|
Everything running on this box's Docker, not just the routed apps. CPU/MEM sampling asks dockerd for a real 1-second delta, so it takes a moment.
Searches this server's VictoriaLogs — Docker container output, infra error logs and the host journal — shipped by the logger agent. Newest first. Click a row to expand it; click a container or level to filter by it.
| Time | Source | Container | Level | Message |
|---|
Every request that reaches this box's edge proxy (Caddy), tailed live from its access log in VictoriaLogs. Newest first. Click a row to expand it — full headers, forward chain and the request body; click a client, method, status or app to filter by it. Bodies are not captured on credential routes (/auth, /vault) or large-upload routes (/apps, /llm).
| Time | Client | Method | Status | App | Path | ms | Size |
|---|
Every week this box pushes its data to its peer box and stores the peer's snapshots in return, so one dead disk never loses data. Every database is included (MySQL dump, SQLite stores, volume DBs); anything re-downloadable from the internet (fetched media, model caches) is not. Managed by infra backup in the infra repo.
| Time | Result | Detail |
|---|
Every test repeats a fixed unit of work for a fixed time, so the numbers compare across boxes. Scores are relative to one njvhost core — 1000 means njvhost-class per core, 2000 means twice that. Each test also keeps its own unit, because a score is for ranking and MB/s is for deciding. Run it on every box at once from the fleet dashboard's Lab tab.
Each worker is a real OS thread grinding a heavy math kernel for a fixed time budget. The numbers are work throughput — bigger is better. Knobs are clamped server-side so the box can't be melted. Watch the Monitor tab to see the cores light up.
The box fires real HTTP requests at its own listener over loopback against a tiny endpoint, as many in flight at once as you ask for. The load is generated from worker threads on other cores, so the server's event loop is the only thing under test (not sharing its core with the load generator), and keep-alive connections are warmed up first — so the numbers reflect the server's real steady-state capacity. It reports throughput (requests/sec) and the latency distribution. The sweep ramps concurrency 1→N so you can see where req/s plateaus and tail latency starts to climb. Watch the Requests graph on the Monitor tab light up.
⚠️ Aggressive — this is built to find the breaking point, so the server may drop requests or briefly restart under it. Each run is time-bounded and only stresses this one container, which recovers when it ends. Keep-alive runs warm their connections first, so the break reflects real request-handling saturation (and so varies by hardware). New connection per request is the harshest setting and measures something different — connection-setup limits: it churns sockets and can exhaust ports. Pair it with the heavy /metrics target to push hardest.
Generated entirely in your browser — nothing is sent to the server. Higher error correction survives more damage/dirt on the printed code but holds less data. Point any phone camera at the result to scan it.