Skip to content
Mimir

Acknowledging alerts

Acknowledging alerts

Mimir tracks one disposition per alert: acknowledged or not acknowledged. There’s no separate “false positive,” “true positive,” or “in progress” state. The intent is to keep triage fast: an alert is either still demanding attention, or it isn’t. This page is the guide to that single workflow and the small ergonomics around it.

What “acknowledged” means

Acknowledging an alert sets acknowledged_at to now and acknowledged_by to your username on the server side. The alert stays in the database forever (acknowledge doesn’t delete or archive); it just drops out of the default Unacknowledged filter on the Alerts page so the queue gets shorter.

You can always pull acknowledged rows back into view by switching the Acknowledged select on the toolbar to Acknowledged or All.

The acknowledge action is gated by withAnyAuth — any signed-in user can acknowledge any alert. The audit trail (who clicked, when) is preserved through acknowledged_by and surfaced in the detail pane’s header band (“acknowledged 2m ago by alice@example.com”).

The 5-second undo window

Click Acknowledge (or press A with a row selected) and Mimir does three things at once:

  1. Optimistically dims the row to 60% opacity.
  2. Shows a toast: “Acknowledged. Press U to undo.”
  3. Starts a 5-second timer.

If you press U before the timer fires, the row pops back to normal and the toast updates to “Ack undone.” Nothing ever hits the server. This is the safety net for the common fat-finger case where you meant to navigate, not acknowledge.

If you don’t press U, after 5 seconds Mimir calls PUT /api/v1/alerts/<id>/acknowledge and the dim becomes permanent. The next unacknowledged row is selected automatically so your j / k rhythm continues.

If you acknowledge a different alert before the timer fires on the first, Mimir commits the first one immediately and starts a fresh 5-second window for the new one. There’s only one pending acknowledge at a time — single-slot, by design.

If the commit fails for any reason (network blip, server error), the optimistic dim is removed and a red toast surfaces the error. The row returns to the unacknowledged state.

Bulk acknowledge: “ack everything in this group”

Switch the Group mode segment to By Host or By Category and each group header gets an Acknowledge all button. Clicking it sends a single POST /api/v1/alerts/acknowledge-where with a filter body (host_id, severity, ioc_source, category — whatever the group is keyed on). For the bulk-by-id case (acknowledging a set of specific alert UUIDs at once), the underlying call is PUT /api/v1/alerts/bulk-acknowledge with a JSON {ids: [...]} body.

Common patterns:

  • Group by host, ack the noisy one. A decommissioned VM is still generating alerts. Group by host, find its row, click Acknowledge all on the group header. Every alert tied to that host is acked in one round trip.
  • Group by category, ack the compliance noise. Compliance alerts ran during a scheduled maintenance window and you’ve already triaged them as expected. Switch to By Category, ack the entire Compliance group.
  • Group by source (via filter), ack the historical batch. Set the source chip to Historical, optionally pick a severity, then group by host and ack the group header. The bulk filter body inherits the source chip selection so you don’t catch unrelated watchlist alerts.

Bulk acknowledge is not undoable — there’s no 5-second window because the operation is intentional and explicit. Re-opening the acknowledged group requires switching the Acknowledged select to All or Acknowledged.

Filter round-trip

The Acknowledged toolbar select drives the URL’s acknowledged query parameter, which round-trips through the browser back/forward buttons and bookmarkable URLs:

  • ?acknowledged=false (the default) — only unacknowledged rows.
  • ?acknowledged=true — only acknowledged rows.
  • ?acknowledged= (empty) — everything.

The same parameter is consumed by exports: a CSV / JSONL download of an Acknowledged view returns only the acked rows. Useful for handoff at end-of-shift.

Disposition is a per-alert concept, not a per-indicator one

If two hosts match the same IOC and produce two alerts, you acknowledge each one independently. Acknowledging one doesn’t silence the indicator — it’s still active, still matching. If the indicator itself is producing genuine noise, the right move is to deactivate the IOC on the Indicators page. Acknowledge is for “I’ve seen and triaged this signal”; deactivate is for “stop the signal entirely.”

Why no richer disposition states?

A common request, and a deliberate non-feature. Adding a multi-state disposition (false positive / true positive / in-progress / resolved) creates a coordination problem: two analysts on the same alert disagree, or the state lives long enough to go stale. Mimir’s v1 answer is to keep the queue binary and use the host detail and IOC history pages for the “what was this and why” context. If your workflow needs more state machinery, that lives in your ticketing system; Mimir can drive it via the webhook integration.

Troubleshooting

“Ack failed” toast appears after pressing A. The server returned a non-2xx, most likely 401 (session expired). Refresh the page and sign in again; the row should re-appear as unacknowledged. Persistent failures point at server-side issues worth bringing to your admin.

Acknowledge button doesn’t appear in the detail pane. The alert is already acknowledged. The detail header band shows the timestamp and username instead.

U doesn’t undo. Two cases. The 5-second window has already expired (the commit went through). Or you started a new acknowledge in between, which collapsed the prior one. In either case, switch the Acknowledged select to Acknowledged to find the row and decide whether you need to reach for the server to undo it manually — there’s no UI undo past the 5s window.

Where to next