Skip to content
Mimir

Live event map

Live event map

The Live event map is the rotating globe at /map. Every host in your fleet shows up as a dot at its location, every interesting event the server sees draws an arc landing at the server’s location, and a side rail captures the running play-by-play. The page is the showcase view: it’s the right thing to project on a wall in an operations room, and it’s also a useful at-a-glance read for “is anything going on right now?” during an active investigation.

What you get

The page is one big globe canvas and one right-side rail.

Header strip. A small status row across the top:

  • A pulsing LIVE dot and the running count of events this session (LIVE · 247 events this session).
  • On the right, the server identity — server: <name> · <lat>°N, <lng>°W — pulled from the same bootstrap call that places the globe’s home base.

The globe. A rotating 3D globe.

  • Host dots. Every enrolled host with a known location is plotted at its lat/lon. The dots stay put while the globe spins beneath them.
  • Event arcs. Every event from the live WebSocket stream draws an arc from its origin to the server. Lower-severity events originate at the host’s own location, so most arcs read as “fleet activity converging on HQ.” Attack-severity events (critical or high) originate at one of a fixed pool of global C2 cities — so a real alert flashing across the globe looks like a global threat striking the server, not a friendly heartbeat.
  • Color coding. The legend at the bottom of the canvas explains the four arc colors:
    • green — heartbeat
    • blue — info
    • amber — compliance
    • red — security
  • Overlay panel. Top-left of the canvas: a compact Online agents count above of N enrolled. Tracks the live agent population, so you can see when a region of the globe goes dark.

Controls. Bottom-right of the canvas:

  • ◐ Rotating / ◐ Paused — toggle auto-rotation. The globe rotates by default; pause if you’re trying to read a cluster of dots in one region.
  • Clear — wipe the running arc set and the side-rail feed back to empty. Useful when you’ve been letting the page play for a while and want a fresh read.

Stat row. Below the globe, four counters:

  • Events this session — total events since you opened the page (or since the last Clear).
  • Online now — live online count with a percentage of enrolled below it.
  • Critical this session — count of critical-severity events in the current session, with the subtitle IOC · tamper · FIM hinting at the kinds of events that contribute.
  • Cities active — distinct cities the session has seen events from, expressed as N of M known.

Side rail — Live event feed. Up to 14 most recent events. Each row has:

  • A severity tag (OK, INFO, MED, HIGH, CRIT).
  • The event category.
  • The event message + the originating host id.
  • A relative timestamp.

The feed pushes older entries off the bottom as new events arrive.

Why use it

Three patterns:

  1. Operations-room display. A globe with a running event feed is the kind of view a security operations team wants on a wall monitor. It catches the eye when a normally-quiet region suddenly produces a wave of critical-severity arcs.
  2. Ambient awareness. Leave it open on a side monitor during an incident-response window. The Online now overlay and Critical this session counter tell you whether things are getting better or worse without you having to switch tabs.
  3. Demo and reporting. Coordinated activity (a malware wave sweeping the fleet, a regional outage causing heartbeats to stop) is more legible as a moving picture than as a table of rows. The page is a useful way to show what Mimir’s seeing without making a viewer read SQL.

How to use it

  1. Open /map from the left nav.
  2. Wait a few seconds for the bootstrap fetch to resolve and the globe to render. While bootstrap is loading you’ll see Connecting… in the canvas; once it resolves the server metadata line at the top updates from connecting… to the real server identity.
  3. Watch the feed. Click ◐ Rotating to pause and read a region, click again to resume.
  4. Click Clear when you want to reset the counters and sparse the canvas.

Severity, arcs, and what’s “active”

The mapping from event to arc:

  • info / OK (green / blue arcs) — routine heartbeats and status messages. Most of what the feed sees on a healthy fleet.
  • med (amber arcs) — compliance or notable but non-emergency activity.
  • high and crit (red arcs) — attack-severity. These originate at one of the global C2 pool cities (not at the host’s own location) so a critical event reads visually as “external attack on HQ” — exactly the framing it deserves on a wall display.

The Critical this session counter only counts crit events, not high.

The Cities active counter counts every distinct city that’s contributed any event in the session, so the number grows monotonically until you Clear.

How the data gets to the globe

Two channels:

  • Bootstrap (HTTP). On first load, /api/map/bootstrap returns the server’s location, the full enrolled-host set with locations, the online count, and how many distinct cities Mimir has ever seen events from (used in the of M known subtitle). The page retries with exponential backoff if the bootstrap fetch fails, surfacing a toast on the third attempt so you know the connection isn’t healthy.
  • Stream (WebSocket). /api/map/stream delivers events as they arrive. The page auto-reconnects with exponential backoff if the socket drops, so a brief network blip doesn’t require a reload.

Events that arrive before the bootstrap completes are buffered and flushed once the server location is known, so you won’t see “arcs to nowhere” during a slow initial load.

Permissions

Both endpoints are gated by withAnyAuth — any signed-in user can view the map. There is no per-host or per-region access control: every signed-in user sees the same globe.

Troubleshooting

The globe never appears, only Connecting…. Bootstrap is failing. Wait for the third retry — a toast will appear saying “Map bootstrap unavailable — retrying…”. If the toast appears, the server isn’t reachable; check the operator logs.

The session expired on me. The bootstrap fetch returns 401 or 403 when the session lapses; a toast surfaces “Session expired — please log in again.” Sign back in and the page resumes.

The globe renders but no arcs ever appear. The WebSocket isn’t connected, the fleet is genuinely quiet, or your session doesn’t have access to the event stream. Open the browser’s dev tools and check for /api/map/stream errors. If the socket is open but no events flow, the fleet is truly idle — leave the page open and any real activity will show.

Arcs originate from cities the host isn’t actually in. Critical and high-severity events deliberately originate at one of a fixed pool of global C2 cities, not at the host’s own location — this is the “attack hitting HQ” visualization described above. Lower-severity arcs do originate at the host’s own location.

The Cities active counter shows fewer than I expect. Cities are only added when an event is seen from them in the current session — not from the bootstrap-time fleet membership. Wait for more activity, or check of M known to see how many the server has ever recorded.

Where to next

  • Dashboard — the table-shaped version of the same operational status.
  • Fleet intelligence — when a wave of critical arcs catches your eye, the intelligence page is where the underlying events cluster into something you can act on.
  • Alerts — the canonical feed of every alert (the rail on the map is a rolling glimpse of the same stream, capped at 14 entries).