Skip to content
Mimir

Host detail

Host detail

Click any hostname in the Hosts list to open that host’s detail view. It’s the single place Mimir aggregates everything it knows about one endpoint: recent telemetry, the pack results that drive your security posture, IOC history, and any compliance signal collected by osquery. If you’re triaging an alert, investigating a suspect machine, or just spot-checking what an endpoint is running, this is where you go first.

What you get

The detail view is organized as a header strip plus a stack of sections:

  • Header strip — Status (online/stale/offline), OS family + version, CPU architecture, last-seen IP, the timestamp of the most recent agent check-in, the agent version, the osquery version, and when this host first enrolled. Every value is computed from the latest agent heartbeat — there is no external CMDB sync.
  • Pack sections — One collapsible section per scheduled osquery pack the agent runs. Each section renders the latest pack result the server has ingested. Common defaults: process snapshots, installed software, listening sockets, scheduled tasks, user accounts. The exact set depends on which packs are enabled for the tenant.
  • Compliance — The pass/fail status of any compliance policies that matched this host (e.g. “BitLocker enabled”, “screen lock < 5m”). Rendered from the compliance osquery pack output.
  • IOC history — Every IOC alert that was ever raised against this host, with the indicator value, source feed, and the watchlist / hunt / historical scan that surfaced it. Lets you see “what bad things have ever fired on this box” without leaving the page.
  • Timeline — A reverse-chronological feed of significant agent events (enrollment, decommission, cert renewals). Useful for “when did this host go quiet” investigations.

Sections are collapsible: click the heading to expand or hide. Mimir remembers your collapse state for the session.

Why use it

The detail view is your fast-path for one-host triage. Two scenarios dominate:

  1. Alert investigation. An IOC alert points at a hostname; you want to see what else is happening on that machine — what processes are running, what binaries are installed, when the agent last checked in. Host detail puts all of that on one page.
  2. Posture verification. You shipped a new policy and want to spot-check that a representative host actually has the new config. Open the host, expand the relevant pack section, confirm the data.

Power users tend to keep the Hosts list open with the search filter primed, then open detail views in new tabs. Mimir’s routes are stable, so /hosts/<id> is bookmarkable and shareable.

How to use it

  1. Open the Hosts page from the left nav.
  2. Find your host. Use the search box if the fleet is large — it matches hostname, IP address, OS name, and OS version (case-insensitive substring), with a 250-millisecond debounce so typing feels instant.
  3. Click the hostname link. The detail page loads at /hosts/<id>.
  4. Skim the header strip to confirm the host is the one you expected.
  5. Expand any pack section to see the latest osquery rows. Use the IOC history section to check whether this host has ever produced a hit.
  6. To go back to the list, use the Hosts › breadcrumb at the top of the page or your browser back button — the list preserves your search and filter state.

Troubleshooting

“Host not found.” The host id in the URL is unknown — the host may have been decommissioned, or you copied a partial id. Either decommissioned hosts are still queryable (the detail page works on hosts marked offline), or the id genuinely doesn’t exist. Double-check the URL.

Sections never load past “Loading details…”. The detail endpoint returns the latest pack result per scheduled query. If the host hasn’t reported any pack data yet (newly enrolled, or only the heartbeat has come through), sections render empty. Wait a few minutes for the next pack interval.

Last-seen timestamp doesn’t match the header strip’s status. The status field is bucketed by configured thresholds: online while the last contact is within the MIMIR_STALE_AFTER window (default 10 minutes), stale past that, offline past MIMIR_OFFLINE_AFTER (default 24 hours). Operators tweak these in mimir-server.yaml; the timestamps themselves are always the raw value from the agent heartbeat.

IOC history is empty even though I expect a hit. The IOC history section shows alerts (ioc_alerts table) — not every observed indicator. A real-time watchlist match dedupes within a 24-hour window, so the same indicator matching the same host twice in quick succession only produces one alert. For a freshly enrolled host that hasn’t run any IOC hunts yet, the history is genuinely empty until the next watchlist tick or hunt run.

Permission model

GET /api/v1/hosts/{id} is gated by withAnyAuth — any authenticated user can view any host. There is no per-host or per-tenant access control on the fleet view. If you need to keep specific hosts hidden from specific operators, that boundary is enforced by deploying separate Mimir tenants, not by row-level filtering.