Run a query

The Queries page is Mimir’s ad-hoc SQL workbench. You write an osquery statement, pick a target (the whole fleet, one host, or every host on a specific OS), and click Run query. Mimir dispatches the query, then streams results back as each agent answers. It’s the right tool for the investigations that don’t fit a pre-built pack: “show me every process named svchost.exe on the Windows fleet right now,” “give me the listening TCP ports on this one host,” “list installed software on Macs only.”

What you get

The page is one panel for the editor, one for results, and a right-column rail (covered in Saved queries) for your library and run history.

SQL editor. A CodeMirror-based editor with autocomplete for osquery table names and columns. The autocomplete corpus follows your Target selection: pick “Single host” and the table list reflects what that host’s OS supports; pick a single OS in “By OS” mode and the list narrows to that platform. Multi-OS selection or “Fleet” defaults to the Linux table set as a common denominator — a union would mislead you into thinking Windows-only columns are queryable everywhere.

Target picker. Three exclusive modes:

Fleet — every connected agent runs the query.
Single host — choose from the first 500 hosts in the host list. The dropdown shows hostname (status).
By OS — checkbox per platform with a (count) next to each one. If no platforms are listed, either no agents are connected or the /os-options endpoint failed (Mimir surfaces the error in a toast and in the picker itself rather than rendering a misleading empty state).

The Run query button stays disabled while a stream is in flight, while the target picker is incomplete (no host chosen, no OS ticked), or when the SQL box is empty.

Results panel. Once dispatched, the panel shows the eight-character query id, the progress count N / dispatched hosts responded…, and a slim progress bar. Rows arrive one host at a time over a Server-Sent Events stream. When the dispatch completes or times out, the count becomes the final tally (green if every host answered, dimmed if some didn’t).

If the result set hits the server-side row cap, a small 50K cap label appears next to the export buttons — the rows you have are good; there were more matches that didn’t make it into this batch. Narrow your query or scope.

Export. Once results are in, Export CSV and Export JSON buttons appear. Both are direct download links from the same query id.

+30s extend. If the stream times out before every host answered (a common “fleet has a few slow stragglers” case), an inline +30s button appears next to the export buttons. Click it to reopen the stream for another 30 seconds against the same query id; you can extend up to three times for a total of 120 seconds past the initial window. After the third extension the button disables itself with the tooltip “Extension cap reached (120s).”

Why use it

Three patterns:

One-off investigation. An alert points at a host or a process; you want to ask osquery a question that no scheduled pack covers. Drop the SQL in, scope to the relevant host or platform, hit Run query.
Pack prototyping. Before promoting a query into a scheduled pack, run it ad-hoc against the fleet first. Confirm the SQL is valid on every target platform, that the result set is sized reasonably, and that the columns are what you expected.
Live spot-checks. You shipped a config change; you want to confirm a sample of hosts picked it up without waiting for the next pack interval. Quick fleet query, look at the rows.

How to use it

Open the Queries page from the left nav.
Type or paste your SQL. Use Ctrl/Cmd-Space inside the editor for table and column autocomplete; the suggestion list reflects whichever target you’ve picked.
Click Fleet, Single host, or By OS. For single-host, pick the host from the dropdown. For by-OS, tick one or more platforms.
Click Run query. A toast confirms how many hosts the query went out to.
Watch the results stream in. The progress count tracks how many hosts have answered.
When the run finishes, click Export CSV or Export JSON if you need the rows outside Mimir. If the stream timed out short, hit +30s to wait a little longer.

Loading a past run

The Recent queries rail below the saved-queries library lists your recent runs — click any entry to repopulate the editor with the SQL and target it used, and to reload the results snapshot. Loading an entry cancels any in-flight stream so a slow earlier run can’t clobber the results you’re about to inspect.

Streaming behavior and reconnects

The results panel uses Server-Sent Events. If the connection drops mid-run (a network blip, a server restart, a tab backgrounded by the browser), Mimir tries to refetch the full result snapshot once to catch up on anything you missed during the gap, then marks the run done. You won’t get a second reconnect — a second SSE error on the same query gives up rather than looping. In practice this means you almost never notice a transient drop, but a sustained outage will leave you with a partial result set and the Final: N / dispatched count to tell you so.

Result rows are deduped on the host id, not the hostname. A fleet that contains multiple hosts with the same hostname (typical of cloned DESKTOP-WIN images or repeated localhost aliases) still gets one row per actual agent.

Troubleshooting

“Run query” stays disabled. One of three causes. Check the editor contains non-whitespace SQL. Check the target picker: in “Single host” mode you must pick a host; in “By OS” mode you must tick at least one platform. Or a previous stream is still running — wait for it to finish or reload the page.

The progress bar says “0 / 0 hosts responded…” for a fleet query. No agents matched the dispatch. For “Fleet” this means no agents are currently connected (open the Hosts page to confirm). For “By OS” this means no agents on the selected platforms are connected. The dispatch toast shows the count up front; if it says “Query sent to 0 hosts” that’s your signal.

A stream finishes but the count is “Final: 47 / 80.” 33 hosts didn’t answer within the SSE window. Common causes: those hosts are stale (last seen too long ago to be on the wire), they were busy on another query, or your SQL takes longer than the window on heavily-loaded hosts. The +30s button is the right next step.

The OS picker shows “OS picker unavailable” instead of platforms. The /os-options endpoint returned an error. The picker won’t accept input until it loads. Try reloading; if it persists, the server is unhealthy in a way that needs an operator to investigate.

Autocomplete is suggesting Windows columns on a Linux host. The autocomplete table set is picked at the moment you choose the target; if you switched modes after typing, give it a beat to refresh. If it still seems wrong, the host list itself may not have synced the host’s OS yet — re-open the host picker.

Permissions

The Queries endpoints are gated by withAnyAuth — any signed-in user can run queries against any subset of the fleet they pick. There is no per-host or per-tenant access control inside a single Mimir deployment; the boundary is the deployment itself.

Where to next

Run a query as a campaign — the same SQL workbench, but offline-tolerant: offline hosts catch up on reconnect, and the run leaves a durable record on the Campaigns page.
Saved queries — turn a useful one-off into a named, shareable entry in your library.
Query packs overview — graduate a proven query from ad-hoc into a scheduled pack so it runs on every agent on a recurring interval.
Hunts — for indicator-driven sweeps (hashes, IPs, domains), the hunt path is purpose-built and ranks matches for triage.