Your next incident should not start from zero

The alert looks familiar. Someone remembers a similar failure a few weeks ago. There was a useful query, a misleading symptom, and a fix that finally explained it. Now the team has to find that thread and reconstruct the reasoning.

Our last update brought eight more runtime connectors into Horus. This time, we want to walk through what happens after you collect the evidence: saving the investigation, recording what you verified, and making that knowledge available the next time you need it.

These workflows are available in the published v0.23.0 CLI. The newer background-service work remains a pilot; it is separate from the workflow below.

Keep the investigation you already did

A Horus report brings together collected evidence, ranked hypotheses, gaps, and next checks. Saved investigations let you return to that report after the terminal session ends, without asking someone to repeat the original investigation from memory.

horus investigate "checkout latency spike"
horus investigations

# Replace <id> with a saved investigation ID
horus replay <id> --format markdown
horus postmortem <id> --output ./postmortem.md

Replay uses the evidence already collected. If the incident is still changing, run a fresh investigation to collect current evidence. The postmortem command gives you an editable draft to review and complete with the outcome your team verified.

Record what you actually verified

An investigation can point you toward a cause. Confirming it still takes work. Once you have verified that Horus identified the cause, you can record a confirmed outcome linked to that investigation:

horus memory confirm <id> --note "Verified the missing index caused the slow query"

That note is an example, not an instruction to confirm every report. If the investigation only partly helped, or pointed in the wrong direction, record that honestly with horus feedback <id> --resolved partly or --resolved no. horus memory accuracy summarizes the outcomes you have labeled; it does not manufacture an accuracy score before there is feedback.

You can also capture knowledge that belongs to the project: a decision, a contract, or a pitfall, with a reference to the evidence behind it. Use horus memory add to author a claim and horus memory show <scope> to inspect relevant project context and stored items.

Familiar symptoms still need fresh evidence

Two incidents can look alike and have different causes. A previous fix is a useful place to start checking, but it cannot establish what happened today.

Horus keeps memory scoped to the project. Investigations recall similar past incidents; agent packets can recall authored claims. Older claims carry freshness information, and you can manage knowledge as it changes instead of treating every saved note as permanently true.

Make useful knowledge available to the team

With an optional linked Cloud project, private storage and team sharing are separate. Authored-memory writes mirror to Cloud on a best-effort basis when you are linked and logged in. Sharing an authored claim with the team requires explicit promotion; confirmed-outcome items cannot be promoted.

horus memory promote <id> shares an eligible authored claim, and horus memory pull refreshes the local cache of team knowledge. Attribution stays attached. Recall embeddings remain local. The memory guide explains the storage, sync, and sharing boundaries in detail.

Where the background-service work stands

We are also working on a background incident-memory service. That work remains a pilot with open release gates, and should not be read as a generally available always-on service in v0.23.0. The Cloud release limits describe that boundary.

You can use the saved-investigation and memory workflow today: investigate, inspect the evidence, record the outcome you verified, and leave the next engineer a better starting point. Start with the investigation walkthrough, then explore project memory.