Runbook

What it does: a named sequence of steps you run with one click — a repeatable checklist that actually gathers data instead of just telling you what to go do. Comes with starter runbooks (WAN down triage, App reachability triage, Gateway / uplink degradation, DNS sanity, Cert / TLS health, New device onboarding, Perimeter exposure check, Rogue device check) and you can build your own.

Jobs: six built-in task runbooks sit at the top of the screen — click one, fill in the target and press Run. You also reach them from Tools ▸ Jobs, the command palette (type "job"), and the Jobs widget on the SPOG Help desk board. Jobs can be edited like any runbook (your edits are kept) but not deleted. The six: "Is it the network?" (gateway, DNS, path and the service), "What's on this segment?" (gateway, the ARP cache with vendors, the segment's public IP), "Talk to a device" (ping, MAC/vendor, open ports, SNMP identity, Inventory record), "Prove it to the ISP" (gateway, public IP, per-hop loss and the trace to an outside target), "Switch port check" and "Device health snapshot" (read-only show commands on a switch or router — see Show command below).

Step types: Ping, Traceroute, Path ping, Port scan, DNS lookup, ARP lookup, MAC/OUI lookup, Inventory lookup, Add to inventory, Drift check, Capture drift baseline, SSL check, HTTP check, WHOIS, IP info, SNMP poll, Show command (read-only), and Note. Every one of those except Note actually runs a tool and records a real result; Note is free-text guidance for something you need to do yourself (verify a physical port, get sign-off before containing a device, etc.) — each step's type shows a green AUTO or amber MANUAL tag so it's obvious at a glance which is which.

Auto-fill / chaining: leave a step's target blank and it uses whatever an earlier step in the SAME run already found — an ARP lookup's discovered IP/MAC feeds a following MAC/OUI lookup, Inventory lookup, or Drift check without retyping it. A result shows "(auto-filled)" next to the value it actually used, so what happened is always visible, never silent. (ARP lookup, IP info, DNS lookup, Capture drift baseline, and Note keep their own blank-target meaning instead — e.g. a blank ARP lookup lists the whole cache.)

Steps are editable in place: change a step's type or target directly in the list (no need to delete and re-add).

Show command (read-only): runbooks can run read-only show commands on a device over SSH; the same read-only gate as Multi-host blocks anything that changes config, and output is masked for secrets. Pick the device (a saved host from Console ▸ Saved hosts — its SSH login, Vault-linked or not, is used; an Inventory device works when it has a saved host) and type the command, e.g. "show interface status". It runs over the same SSH path as Multi-host, one command per step, with a 60-second limit per step; hosts set to auto-enable get "enable" first. Anything that isn't read-only — conf t, write, copy, reload, a "show …; reload" chain — is refused and nothing is sent; the refusal is recorded. Secrets in the output (enable secret, user secrets, SNMP communities, keys, your own login if it echoes) become ****** before the result is shown, logged, or added to the case. Write {port} in a command (e.g. show mac address-table interface {port}) and you're asked for an interface name at Run. Jobs: "Switch port check" (interface status, the MACs learned on {port}, the port's counters) and "Device health snapshot" (version, IP interface brief, interface error counters). The Deputy's run_runbook obeys the same gate, and when the Deputy uses a cloud AI it first shows a WARNING naming the host, the commands and the provider the masked output goes to — nothing runs until you click "Run and send" (every time). The Posse runs show steps only with a local model. In demo mode gw-core and sw-access-01 answer with sample output and no device is contacted.

Run-time targets: write {target} or {gateway} in a step and you're asked for it when you press Run, so the same saved runbook works on the next device. "Run on" boxes appear under the runbook picker: {gateway} is pre-filled with this machine's default gateway, {target} when another tool sends you here with a host. Placeholders also work inside a URL (e.g. {target}). The starter runbooks use these instead of example addresses you had to replace.

Where results go: every run is written step by step to the active case — or, with no case active, to a new Incident that becomes the active case. Each step and a run summary also go to the Activity log (tool = Runbook), with known secret shapes in the output masked before they're saved. The new Incident is titled "Runbook: <name> · <target>" (just "Runbook: <name>" when the runbook has no {target}); anything you then Add to… (Ctrl+I) from another tool lands in the same record — that's the one to open for a ticket reply (see Incidents ▸ Make active to pick a case first). A runbook the Deputy runs for you (run_runbook) is recorded exactly the same way. Click any result in the run to jump straight to that Incident; from there, "← Back to Runbook" returns you here. "Copy results" grabs a plain-text dump of the run for pasting straight into a reply, without leaving this screen.

Safe to run: the automated steps are all the same read-only tools used elsewhere in the app (see each tool's own article for specifics — Port scan and SSH/console-driven steps are the ones to be more careful with on systems you don't own). Note steps for containment/config-change actions are deliberately manual — SubnetSlinger never takes an enforcement action on its own.

Reading results: ✓/✕ per step tells you what passed; the auto-fill trail in each label shows exactly what value was used where, so you can trust — and if needed, correct — what the run actually checked.