Guard · Incidents ledger

Incidents ledger

The hosted Incidents tab (Attribution group, /team/incidents) reads your team event store and lists every prevented incident: each measured outcome where a guarding action stopped an incident, the verb for that action, and the dollars it saved. Everything on this page is team-scoped and redacted. The per-incident blame chain that traces a new prod alert back to the commit and session that introduced it is a separate, desktop-only feature, covered on Incident correlator.

Start here if you want to see what your team prevented and what it saved: Accountability ledger (hosted).

What it shows

A prevented incident is an action.outcome event whose measured benefit is positive (benefitUsd > 0) inside the window. The page reads the last 30 days of your team event store and renders:

  • Prevented incidents: the count of qualifying outcome events in the window.
  • Dollars saved: the sum of the measured benefit across those events, in USD.
  • The ledger: one row per prevented incident, newest first, showing a badge for the guarding action, an optional redacted note, the dollars saved for that incident, and the date. Every priced row today comes from the prevention re-key, so the badge reads lesson guard and the row names the brain lesson whose guard recorded the catch. A row recorded against an action event shows that action's verb (for example roll-back-deploy, guard-check, mute-alert), and a row whose action the team event store does not record says action not recorded rather than printing the ledger category it was filed under.

The list is capped at 50 rows, and one read of the window takes at most 5,000 events. A team that streams more than that in 30 days gets a partial window: the page then labels both figures "(at least)" and says they are lower bounds over the rows it read, not totals for the 30 days. This is the same prevented-incident signal the Accountability rollup counts, shown here as its own ledger.

What it does not show

This tab does not correlate a live prod alert back to its cause. Linking a new Sentry, Vercel, PostHog, or DB slow-log alert to the commit and AI session that introduced it runs over the adapters connected on each developer's machine, in the desktop app, and is not streamed to the cloud. The hosted tab names that work and points to the desktop for it.

ⓘ
Two features, one word
The word "incidents" covers two distinct things. This hosted ledger reports incidents your team already prevented by a recorded guard catch, with the measured dollars saved. The desktop Incident correlator blames a live alert on the change it traces to, with the confidence banded. They share a name and nothing else.

Cloud-side vs desktop

QuestionWhere it is answered
How many incidents did the team prevent, and what did that save?Here (hosted). Read from the team event store, team-scoped and redacted.
Which commit and session introduced this new prod alert?Desktop app, Incidents. Runs over the locally connected adapters; not streamed.

Empty state

With no prevented-incident outcomes measured yet, the page says so plainly rather than filling in a table. Once your team's desktops stream outcome events, each prevented incident renders here with its verb and dollars saved. To blame a live prod alert back to its introducing change, open the desktop app, go to Incidents, and wire the adapters under Settings, Connect.

Read more

Last updated