Operator Search: A Slash-Command for Everything

Slash, type, jump. Resources, runbooks, dashboards, incidents, agents, all keyboard-driven, all in one box. With a fullscreen mode for the incident bridge.

Why one search box

The previous nav had eight tabs. The eighth tab was always the one you wanted. Engineers already had keyboard muscle memory for VS Code, Linear, and Slack, all of which use a slash-command palette, and our nav was the awkward outlier asking them to mouse around. Operator Search collapses the whole nav into one box, bound to slash, and spending the first hour of your week re-learning it pays off forever after.

The other reason: incident response is keyboard-bound. During a 4am page, the on-call engineer has one window of attention and zero patience for menu hunting. A slash-command that jumps straight to the affected service, its dashboard, the active incident, or the relevant runbook is a meaningful reduction in cognitive load.

What it searches

Five scopes, all live: services (anything in your registry), dashboards (yours and shared), runbooks (versioned, with the most-recent edit shown), incidents (open and historical, last 90 days), and agents (named agent recipes you've built). The search prefix narrows the scope, type s/ for services only, d/ for dashboards, and so on. No prefix searches all five and ranks results by recency and your access patterns.

Result rendering matches the source. A service result shows status colour, owning team, and current alert count. A dashboard result shows a 200-pixel sparkline thumbnail. A runbook shows the trigger and last-run timestamp. An incident shows severity, age, and the on-call name. The result list isn't a list of strings, it's a list of objects with enough context to decide without clicking.

The index

The index is updated incrementally on every write. New service registered? Indexed within 200ms. Dashboard saved? Indexed before the save dialog dismisses. Runbook edited? Indexed before the diff page renders. We use a single inverted index over a Postgres-backed tsvector with a custom tokenizer that handles service-naming conventions cleanly (billing-api-v2 matches "billing", "api", and "v2" independently).

Search latency is the metric we care about. p50 across our largest tenant is 23ms; p99 is 71ms. Both numbers include round-trip from the browser. The slow path is when a search hits cold rows, first query of the day on a service that hasn't been touched in weeks, but those tail latencies are still under 200ms.

The ranker is boring on purpose. BM25 plus a recency boost plus a personal-access-pattern boost. We tested a learned ranker briefly and it added 30ms of latency for a 1% relevance lift, not worth it. The boring ranker wins.

Fullscreen mode

Pressing slash twice opens fullscreen mode. The whole window becomes the search palette, results are larger, and a pinned set of keyboard shortcuts shows along the bottom. This is the mode we built for the incident bridge, when an engineer is screen-sharing during a war-room call, the room can see what's being searched and why, without straining at a 14px sidebar.

Fullscreen mode also auto-focuses on the most likely next action. If there's an active P1 incident, the cursor lands on incident-scoped search by default. If there's no incident but the engineer was just on a service page, the cursor lands on service-scoped search around that service. The defaults are usually right; when they're wrong, clearing them is one keystroke.

Keybindings worth learning

Three keystrokes that pay back the time investment. Slash to open. Slash twice for fullscreen. Cmd-Enter on any result to open in a new tab without losing the search context, useful when you're triaging and want to keep the search palette open. The full keybinding map is in settings; these three cover 90% of the actual usage.

One last thing. The search box is exposed via a public /api/operator-search endpoint with the same query semantics. A handful of teams have wired it into their own internal tools, the engineer's homegrown "what's broken right now" page calls our search API for incident scope and renders the results in their team's design system. We don't promote this heavily but it's there if you want it.