Saved hunts, and how not to lose one

You clicked the bin icon beside a saved hunt to tidy up the list, and it vanished before you had a chance to change your mind. That is exactly what happened: the Delete control on a saved hunt has no confirmation dialog behind it. Unlike almost every other destructive action in the console, there is no are you sure, no type-to-confirm, and no undo — the click and the deletion are the same event.

What Save current query actually keeps

Building a hunt on the Threat hunt screen and choosing Save current query stores the query itself along with a name, a description, the dataset it runs against, and the MITRE technique you associated with it, if any. It does not store any results — a saved hunt is a reusable question, not a snapshot of an answer, and running it later reads current data.

Run on a saved hunt executes it fresh and shows you today's results; it does not require rebuilding the query. That part of the workflow is solid — it is specifically the removal path that has no safety net.

Protecting a hunt worth keeping

• Copy the query text somewhere durable — a document, a wiki page — the moment you are satisfied with it, independent of the console.
• If several people share the hunt library, agree who is allowed to delete entries, since nothing in the product enforces that boundary for you.
• Before you clean up the list, check Run on anything you are about to delete, in case its results turn out to matter more than you remembered.

What to do next

1. Read Threat hunting for how to build the query in the first place, including the field names available.
2. If you lost a hunt tied to a specific investigation, check Incidents and the process tree — the storyline_id filter it describes is easy to reconstruct even without the saved query.