Skip to content

Fleet intelligence

Fleet intelligence

The Fleet Intelligence page surfaces change events Mimir saw across the fleet — new software installed, ports that opened, cron jobs added, users logged in — clustered together so you can scan a few rows instead of a few thousand events. Each cluster is risk-scored and labeled as a single-host anomaly, a small cluster, or fleet-wide, so triage shifts from “what changed?” to “what changed and how worried should I be?”

If the Dashboard tells you something is off, this is the page that tells you what.

What you get

The page is two columns: a narrow left sidebar of filters, and a main panel with a summary strip on top and a cluster table beneath.

Sidebar filters:

  • Hostname — substring search; type a name and press Enter or click Go. The cluster list re-fetches with the filter applied.
  • Min Severity — drop-down with thresholds at All / 2+ (Low) / 4+ (Medium) / 7+ (High) / 9+ (Critical). Severity is the cluster’s worst sample severity; raising the floor hides the noisy bottom of the page.
  • Event Types — checkbox list of every change event Mimir tracks: software add/remove, user add/remove, logged-in-user add/remove, port open/close, cron add/remove, systemd service add/remove, Windows startup item add/remove, fileless process observed/gone. Tick the types you care about; Clear all resets to “everything.”

Summary strip:

  • A big Fleet Health gauge (0–100): green at 80 and up, yellow at 40–79, red below 40. The color is the load-bearing signal — read it the way you’d read a vitals monitor.
  • Anomalies, Changes, Hosts — three counters across the time window. Anomalies turn red when non-zero.
  • Time-window picker on the right: 1h, 6h, 24h, 7d. A refresh button next to it forces an immediate reload.

Cluster table rows from highest score to lowest:

  • Score — a colored pill, 0–100. Red at 70+, yellow at 40–69, grey below. The score is the page’s primary ranking signal.
  • Cluster title with the event type underneath in human-friendly form (software_added → “Software Added”).
  • Hosts — how many hosts this cluster affects.
  • Severity badge — CRITICAL (≥9), HIGH (≥7), MEDIUM (≥4), LOW (default).
  • Timeline sparkline — a tiny bar chart of how many events fell in each time bucket inside the selected window. Useful for “did this all happen in one minute or trickle in over an hour?”
  • Label tag — Single host (anomaly is on one machine), Small cluster (a handful of hosts), Fleet-wide (broad coincidence).
  • When — relative timestamp of the last event in the cluster.
  • A chevron showing whether the row is expanded.

Click a row to expand. The expansion shows:

  • The rank reasons chips — short tags Mimir attached to explain why this cluster ranked where it did (e.g., “low base rate”, “unusual hour”, “host has prior incidents”). Read these like the rationale on a credit-score statement.
  • Affected Hosts — a list of hostname links (each opens the host detail page) with the per-host detection timestamp. If the cluster is bigger than the sample list, a + N more footer tells you so.
  • Raw Payload (collapsed by default) — the JSON event payload Mimir scored, useful when you need to copy a value into a hunt or a query.
  • Acknowledge cluster button — see below.

Why use it

Three patterns:

  1. Morning triage. Set the window to 24h, leave severity at All, scan the top of the table. Single-host high-severity clusters are your priority; fleet-wide low-severity clusters are usually noise from a centrally-managed software update.
  2. Incident response. A user reports “my laptop acts weird.” Put the hostname in the filter and look at every cluster on that one machine, regardless of severity.
  3. Investigation seed. A cluster’s rank-reasons chip says “first time observed in fleet.” That’s your cue to dig: open a few of the affected hosts, look at the raw payload, and decide if it’s worth a hunt.

How to use it

  1. Open Fleet Intelligence from the left nav.
  2. Pick a time window. Default is 24h; for triage start there, for active IR shrink to 1h or 6h.
  3. Optionally narrow with the sidebar — hostname, minimum severity, event types.
  4. Scan the table top-to-bottom. The score pill is the at-a-glance ranking; the label tag tells you “one host” vs. “fleet.”
  5. Click any row to expand. Read the rank reasons, scan the affected hosts, eyeball the raw payload.
  6. Acknowledge clusters you’ve triaged (see below).

Acknowledging a cluster

Click Acknowledge cluster inside the expanded row. Mimir sends the cluster’s fingerprint plus the current time window to the server, which marks the underlying events acknowledged so they don’t re-cluster on the next refresh. A toast confirms how many events were marked, and the cluster drops out of the unacknowledged view.

Acknowledging is window-scoped: the same fingerprint can re-appear in a future window if Mimir sees new events that match it. Treat it as “I’ve looked, this is fine for now,” not as a permanent dismissal.

Reading the score

The risk score blends a few signals:

  • Severity — the per-event severity from the underlying change feed.
  • Cluster shape — single-host anomalies score higher than fleet-wide coincidences (a Tuesday-morning software update across the fleet is louder, but a never-seen-before binary on one machine is much more likely to be malicious).
  • Rate / unusualness — the rank-reasons chips spell out the specific signals that contributed.

A score above 70 is worth opening. Below 40 is usually background. The yellow band (40–69) is where most of the day’s interesting triage lives.

Permissions

GET /api/v1/fleet/intelligence and the acknowledge endpoint are gated by withAnyAuth — any signed-in user can view and acknowledge clusters. There is no per-host scoping.

Troubleshooting

“No changes detected in the last .” Either nothing actually changed (small fleets on a quiet day see this often) or your sidebar filters are excluding everything. Reset the sidebar and widen the time window to 7d before concluding the page is broken.

The hostname filter doesn’t match a host I can see in the host list. The cluster fetch matches against hostnames that contributed events in the window. A host with no change events in the window won’t appear here even if it exists.

A cluster I just acknowledged is still listed. Auto-refresh isn’t on this page; click the button or change the window to re-fetch. The row will drop on the next load.

A fleet-wide cluster scores really high and I can’t see why. Open the row, read the rank-reasons chips, and check the raw payload. The most common cause is a label that looks routine (“user added”) but the event itself is on a privileged user across many hosts at once — that’s exactly what a coordinated compromise looks like at the events layer, so the score is high by design.

Where to next

  • Dashboard — the page-level health rollup that points you here when anomaly counts climb.
  • Host detail — drill into any host named in a cluster’s affected list.
  • Launch a hunt — when the raw payload contains an indicator (hash, IP, domain) worth sweeping the fleet for.