Skip to content
Mimir

Query packs overview

Query packs overview

A query pack is a named bundle of osquery queries that every agent in your fleet runs on a recurring schedule. Where the Queries page is for one-off investigations, packs are the durable equivalent: same SQL, every host, every interval, with the results streamed back and joined onto each host’s detail view. The Packs page is where you see what’s enabled, what’s quietly broken, and what’s contributing the most data.

What you get

The page is a vertical stack of one card per pack, plus a single + Upload Pack button in the header for admins (covered in Custom packs).

Each pack card has a header strip and a footer:

Header strip — left to right:

  • A small colored health dot with hover tooltip:
    • Green: “Healthy — results arriving on schedule”
    • Red: “Silent failure — agents ran but returned no rows”
    • Grey + “Awaiting first result”: the pack is too new to judge
    • Grey + “Disabled”: the pack is paused
  • The pack name — clickable, opens the detail view at /packs/:id.
  • The schedule cadence — every 1h, every 5m, etc., rendered from the pack’s top-level interval.
  • An enabled / disabled pill so the state is obvious at a glance.
  • Admin-only inline buttons: Enable / Disable and Delete.

Footer row — three small counters in tertiary text:

  • N rows (24h) — total rows ingested from this pack across all hosts in the last 24 hours.
  • N hosts (24h) — how many distinct hosts reported any results.
  • The source tag (bundled or custom) anchored to the right.

An optional description line sits between the header and the footer when the pack’s YAML provides one.

Why use it

The list is built for three at-a-glance questions:

  1. What’s running? Scan the names and source tags. Bundled packs are the default coverage that ships with the server; custom packs are what your team has added on top.
  2. What’s quietly broken? The health dot is the load-bearing signal. A pack stuck on “Silent failure” means agents are acknowledging the query but not returning any rows — usually a sign the SQL is wrong on a recent OS update or that the agent lost access to the tables it needs.
  3. What’s expensive? The N rows (24h) counter tells you which packs are the heaviest contributors to your ingestion volume. A pack with millions of rows per day on a 50-host fleet is a candidate for tightening its WHERE clause.

How to use it

  1. Open Packs from the left nav. The page loads the full list at once (no pagination — pack counts are typically <100 per tenant).
  2. Skim the health dots and 24h counters.
  3. Click any pack name to drill into its detail view — the per-query table is where you triage a silent-failure dot to the specific scheduled query that’s empty.

Enable or disable a pack (admin)

Click Enable or Disable on a pack card. The state flips immediately in the list and a toast confirms; on failure the toggle rolls back and a toast surfaces the error. Disabling a pack stops the next scheduled tick — in-flight queries still finish and report their results, but no new ticks dispatch.

Delete a pack (admin)

Click Delete. A confirmation modal asks you to confirm; bundled packs add the line “Bundled packs will not reappear on restart” so you understand the deletion is durable and not a config reset.

If the pack is referenced by one or more compliance policies, the server rejects the delete with a compliance_references error and the UI swaps to a force-delete modal listing each referencing policy. You can cancel, or click Force Delete to proceed and disable every referencing policy in the same operation. The dialog spells out “Force-deleting will disable these policies. This cannot be undone.” The deletion stage is irreversible from the UI; if you need the policy back, re-create it from its source.

Permissions

GET /api/v1/packs (listing) is gated by withAnyAuth — any signed-in user sees the same set. The mutation surfaces (enable toggle, delete, upload) are admin-only. Non-admin operators see the list as read-only; the toggle and delete buttons aren’t rendered and the + Upload Pack button is absent.

Troubleshooting

A pack shows “Awaiting first result” days after I enabled it. The pack’s schedule interval hasn’t fired yet on most hosts, or every host that runs it is offline. Open the pack’s detail view and check the Last Result column per query — a fully blank column points at “never run” rather than “ran and produced nothing.” If most rows show recent timestamps but one query is empty, the silent-failure dot on the list will appear next refresh.

A pack I just disabled is still showing results. Result ingestion is asynchronous. Any rows queued or in flight at disable time still land. The dot stays “Healthy” until the rolling 24h window slides past the last successful tick.

The toggle silently undid itself. A toast appeared with an error message — read it. The most common cause is a server-side validation error from a recent config change, or a transient HTTP error during the optimistic update. Re-try; if it persists check operator logs.

Where to next

  • Bundled packs — the read-only set that ships with Mimir, what each one collects, and why it’s in the default build.
  • Custom packs — author your own YAML, upload it, and inspect the parsed Source YAML on the detail page.
  • Run a query — the right tool for one-off investigations that don’t justify a recurring pack.