Skip to content

Many alerts, one problem, and the change before it

Related alerts fold into one problem that names a suspected cause and lists the changes recorded in the hour before it began. Open a case to own the work, and switch it to incident mode with a commander and a war-room timeline when it matters.

  • Change evidence
  • Incident mode
  • Hash-chained evidence

How it works

From a burst of alerts to a closed case

Correlation runs after every evaluation pass, so a problem forms while the alerts are still arriving.

  1. 01AlertMonitors raise alerts per resource, from services, hosts, devices and security rules alike.
  2. 02CorrelateEach new alert joins a related problem: same resource, same monitor, a rule you wrote, or a silent collector.
  3. 03ExplainThe problem names a suspected cause and the changes recorded in the hour before it began.
  4. 04OwnOpen a case from the problem: critical problems become P1 cases, warnings P2.
  5. 05RespondPromote the case to an incident with a commander, a response status and a war-room timeline.
  6. 06CloseThe problem closes when every member alert has ended; a related alert within 30 minutes reopens it.

Correlation

Related alerts become one problem, and it says why

Every member of a problem shows why it joined. Built-in rules catch alerts on the same resource or from the same monitor, and correlation rules you write catch the rest, such as everything on one checkout path.

  • When a collector stops checking in, it becomes the established cause of the device alerts behind it
  • Correlation rules merge alerts that share monitors or labels within a window you set, after a 24-hour preview
  • Merge two problems, or split an alert out, when the grouping is wrong

Cases

Work it as a case, run it as an incident

A case gives a problem an owner, a priority and a record. Promote it to an incident and it gains a commander, a response status and a war-room timeline that captures every change and comment.

  • Owned

    Status, priority from P1 to P5, tags, and the problems and alerts behind it.

  • Incident mode

    A commander, a response status from active to postmortem, and a timeline.

  • Evidence that holds

    Alerts, entities, notes and queries are snapshotted and hash-chained.

  • One click from a problem

    Critical problems open as P1 cases, warnings as P2.

AI sweep

A second look across every open problem

The AI sweep reads the summaries of your open problems and suggests which ones share a cause, what priority they deserve and which evidence is still missing. A person accepts or dismisses each finding.

  • Reads problem summaries, never raw telemetry
  • Off until you run it or schedule it, on the Anthropic model connection your organization adds
  • Ask Brain to merge or split problems and update cases; each change is a proposal you confirm

FAQ

Questions incident teams ask first

Does Tracix decide the root cause?
Only when it can show it: a collector that stopped checking in is the established cause of the alerts it was collecting. Otherwise Tracix names a suspected cause, the worst and earliest alert, and lists the changes before it, so a person decides.
Which changes count as evidence?
Deployments from your CI or the API, Kubernetes rollouts, CI pipeline runs, configuration-change traps from network devices, configuration reverts from Tracix, collector policy and pipeline pushes, and cloud security-group drift.
Can a case open a Slack or Teams channel?
Not yet. Notification policies post alerts to Slack and Microsoft Teams, and a workflow playbook can create a Slack channel for critical security alerts, but a case does not open a channel of its own.
Does Tracix write postmortems or run a status page?
Not yet. Postmortem is a response status on the case, and its war-room timeline and evidence locker hold what you need to write one. Tracix does not publish status pages for your services.

See your alerts as problems

Turn on a few monitors, and the correlator starts folding related alerts into problems on its next pass.