Saved queries

The Saved queries rail is the right-column workbench on the Queries page. It’s where one-off SQL becomes a named, shareable entry you can re-run in a click. If you find yourself re-typing the same query, save it. If a teammate needs to run it too, share it. Mimir handles the storage; you handle the prose.

What you get

The rail has a sticky header and a scrolling list.

Header. A + Save this query button takes whatever you’ve typed in the editor plus the current target and opens the save modal. The button is disabled when the SQL is empty or the target picker is incomplete — the tooltip explains which one is blocking.

The list. One row per saved query. Each row shows:

The name, in monospace. Click it to load the query — the SQL goes back into the editor and the target picker restores to whatever was saved (Fleet / single host / OS list).
A scope chip — Fleet, 1 host, the OS name, or N OS for multi-platform.
A shared pill if the query is visible to your team.
For queries you own, three inline buttons: Edit, Share / Unshare, and Delete. For queries owned by others, you see by instead — no edit or delete from the borrower side.
A per-row action menu with Launch as campaign — sends the saved query through the offline-tolerant campaign pipeline instead of the live-only Run query path. Available on both your queries and borrowed ones.

Why use it

Three patterns:

Personal cheat sheet. Investigations you keep coming back to — “every process started by my user in the last hour,” “listening ports on the gateway box.” Save them, name them, re-run with one click.
Team playbook. Mark the well-tuned investigation queries as Share with team and they show up in every other operator’s rail with by <you> attribution. The next analyst on shift gets your work for free.
Pre-flight for packs. Saved queries are a holding pen between ad-hoc and a real scheduled pack. Iterate on the SQL until you’re happy, save it under a clear name, and only then graduate it into a pack.

How to use it

Save

In the editor, type the SQL and pick a target.
Click + Save this query. The save modal opens with the SQL, target, and name field. The target is captured as a read-only chip — to change it, close the modal, change the target, and re-save.
Give the query a name (up to 120 characters; required).
Optionally tick Share with team. Sharing is reversible per query — anyone can flip it on later from the row.
Click Save. The new row appears at the top of the rail and a toast confirms.

Load

Click the query name. The SQL goes back into the editor and the target picker restores. The query doesn’t auto-run — review and click Run query when you’re ready.

Edit

Click Edit on a query you own. The modal opens prefilled with the current name, SQL, and share state. Update what you need; the target chip is read-only (rebuild a query under a different scope by saving a new entry instead).

Click Share / Unshare on a query you own. The list flips the state immediately, then reconciles with the server. If the server rejects the update, the toggle rolls back and you get a toast.

Delete

Click Delete on a query you own. A confirmation modal asks “Delete saved query? '' will be removed from your library. This cannot be undone.” Confirm to remove. Deletes are optimistic — the row disappears from your view first and the server call follows; on failure the row re-appears and a toast surfaces the error.

Launch as campaign

Open the per-row action menu and click Launch as campaign. The modal pre-fills the SQL from the saved query and the target from the Queries-page editor — by default the editor’s target wins, so you can re-target a saved query without rewriting it. Tick Use saved query’s target to have the saved query’s stored scope override instead.

If the saved query’s stored scope is OS-filtered (os_in), the launch is rejected up front with a modal error:

Campaigns don’t yet support OS-filtered targets — pick Fleet or specific hosts instead.

On success the page navigates to the campaign’s detail view. See Run a query as a campaign for the offline tolerance, per-host row cap, aggregate auto-stop, and the difference from a hunt.

Naming and duplicates

Each owner’s library is uniquely keyed on name within their own set. If you try to save a name you’ve already used, the server returns 409 and the modal renders:

You already have a saved query named "". Rename it or pick a different name.

Two different operators can both have a saved query called top processes — your namespace is per-owner. Renaming a borrowed query isn’t possible; the Edit button is owner-only.

A shared query is visible in every signed-in user’s rail. Borrowers can load and run it; they cannot edit, unshare, or delete it. If you unshare or delete a query that others were loading from, their next refresh won’t see it — Mimir doesn’t track who copied the SQL out into their own editor, so unshares are clean from your end but borrowers may have local edits in their editor that don’t roll back.

There’s no team-wide “library” view; shared queries simply appear inline alongside your own. Sort order is newest-first.

Troubleshooting

”+ Save this query” is disabled even though I typed SQL. The target picker is incomplete: in “Single host” mode you haven’t picked a host, or in “By OS” mode no platforms are ticked. The tooltip on the disabled button says “Enter SQL and pick a target to save.”

A duplicate-name error fires even though I don’t remember saving it. Check whether you have a saved query with that name owned by you and hidden behind a long scroll, or one that’s currently shared by you that shows under the “shared” pill. The 409 fires on the (owner_id, name) pair regardless of share state.

A borrowed shared query disappeared between refreshes. The owner unshared or deleted it. There’s no notification; the row simply drops out of your list on the next fetch.

Edit and Delete buttons aren’t showing on a query I think I own. Either the query is owned by a different account (look at the by … attribution line), or your session lost its user id. Reload the page; if the buttons still don’t appear, you’re signed in as someone else.

Where to next

Run a query — the editor and target picker behavior is documented end-to-end on the runner page.
Run a query as a campaign — launch a saved query offline-tolerant, so the durable run picks up hosts that reconnect later.
Query packs overview — turn a saved query into a recurring scheduled pack once it’s stable.