The Streaming Console: A Live Terminal That Remembers Everything

Most network tooling forces you to choose between two bad options. Either you SSH into a device and lose everything you typed the moment the session closes, or you run a heavy automation pipeline that takes fifteen minutes to schedule a one-line check. The Streaming Console is the middle path: an interactive shell that captures every byte, parses it into findings, and stores the result against the workspace.

Anatomy of a run

A run is the unit the Streaming Console produces. Each run rows into netops_runs with a script reference, a target inventory snapshot, a status, and timing metadata. The streamed output lives in append- only chunks so you can scrub through it later exactly as it appeared, including ANSI colour codes.

Why streaming matters

Long-running diagnostics — show tech-support, packet captures, BGP table dumps — produce thousands of lines. Buffering them until the script finishes is the difference between a tool engineers love and one they tab away from. The console uses server-sent events so the first byte hits the browser as soon as the device emits it.

From bytes to findings

Every script ships with a parser. The parser is a pure function that consumes the raw output and emits zero or more findings into the run. A parser for a BGP health script might emit one finding per neighbour that is not in Established; a parser for an interface check might emit one per port with CRC errors above a threshold. The console writes those findings during streaming, not after, so the RCA panel can see them the moment they appear.

Targeting and inventory

You target a run by selecting devices from inventory. The console snapshots the inventory rows you chose into the run record so a re-run six months later still knows exactly what hostname, IP, and credentials were used — even if the inventory has changed.

Safety rails

Every script declares whether it is read-only or mutating. Mutating scripts require an explicit confirmation step and are blocked entirely in workspaces marked production-locked. The console surfaces this in the run header so nobody runs config replace on a Friday afternoon by accident.

Re-running and chaining

Any run can be re-executed from its detail view with the same inputs, an edited input set, or against a different device. Re-runs are linked, so you can ask: "show me every BGP check we ran on this device in the last week" and get a clean timeline.

Why a custom console instead of SSH-in-a-tab

A browser-based xterm would have been faster to ship. We chose a custom console because three things only work when the platform owns the byte stream: real-time finding extraction, RLS-scoped audit logging, and deterministic re-runs. SSH-in-a-tab gives you the live experience and nothing else.

Scripting hooks

Scripts can declare pre-flight checks (validate inventory shape, confirm credentials), post-flight hooks (push findings into a ticket, open a runbook), and structured prompts (ask the operator for a peer ASN before the script runs). All of it is declarative; the console renders the right UI.

Performance

The console can comfortably handle a hundred concurrent runs against a single workspace. Output chunks are batched on the server before being flushed to clients to keep websocket frames sane, and parsers run in a worker so a chatty script never blocks the UI.

Operational tips

• Pin the scripts you run weekly to the top of the script picker — the console respects pin order.
• Use the tail-only view when you only care about the last few lines of a long capture; the full output is still saved.
• Rename runs with a one-line summary so future-you can find them in history search.

Where to go next

Once you have a few runs in the system, head to the RCA panel and watch the chain form. Then open Compliance and watch the same findings light up rule violations. The Streaming Console is the producer; the rest of the platform is its audience.