Filtering and search

The / filter: substring search, field:value restrictions, and how it composes with namespaces and owner scope.

Press / to filter the current table live. Filtering is a pure, client-side predicate over the rows already loaded, so it is instant and never hits the API. It composes with everything else: the namespace scope, the owner-scope toggles, and the view you are on all still apply, and the filter narrows what is left.

How the query works

The text you type is split on whitespace into terms, and the terms are ANDed together: a row is kept only if it matches every term. Each term is one of two things.

  • A bare substring matches against the row’s name and every rendered column. Typing gcp keeps any row where gcp appears anywhere.
  • A field:value term restricts the match to a single column. provider:gcp keeps only rows whose PROVIDER column contains gcp.

Because the terms are ANDed, you can stack restrictions:

provider:gcp status:stopped

keeps the rows that are both on GCP and stopped. Field names are the column titles, lowercased (status, provider, address, target, and so on).

Press esc to clear the filter and see the full table again.

Tip

The same accessor feeds both the rendered cell and the filter, so a row always filters on exactly the text you see in its columns. There is no hidden field that matches differently from what is on screen.

The relations filter

When you drill into an object’s relations (the x key, see Inspecting), the result is shown as its own Related view rather than as a filter over the current tab. The Related view is a purpose-built, read-only list of the exact related objects, so it stays distinct from the free-text / filter you drive by hand.