Find the root cause,from technical failures to business breakdowns.

A model built for your business. Deterministic answers, and it grows with you.

Trusted by

ProductionSR

Newest firstAll sourcesAny incidentAny class Entity, alert or signal Export Create incident

AlertEntitySeverity & incidentsBaseline → valueDeviationTime

Triage AgentCheckout latency and errors after payments pool change4 alerts

payments-svc pool waits rose first. checkout-api and orders-svc call it synchronously and breached within a minute, and the storefront's error rate followed two minutes later.

Dismiss Create incident

error rate spikehttp.server.5xx.rateweb-storefrontP10.2 → 6.8%+3300%Oct 19 14:14:00+3m

latency p99 breachhttp.server.duration.p99checkout-apiP1180 → 2600ms+1344%Oct 19 14:12:00+1m

rpc timeoutsrpc.client.timeoutsorders-svcP20 → 41/minfrom 0, no %Oct 19 14:12:00+1m

pool wait highdb.pool.wait_p95payments-svcP212 → 1900ms+15733%Oct 19 14:11:00+0m

cpu highcontainer.cpu.utilizationsearch-svcP341 → 78%+90.2%Oct 19 14:10:00-1m

dropped spansotelcol.exporter.send_failedotel-collectorP40 → 1000/minfrom 0, no %Oct 19 14:08:00-3m

2 alerts in view2 entities0 P12 ungrouped0 P1 ungrouped

Event stream inv_c4a9e1

Leading suspectpayments-svc agrees with the initial causal ranking5 of 5 frozen events in the graph

Causal GraphCausal CandidatesCausal ExplanationSignals

Root cause

payments-svcservice

#1Config changeconfig.pool.max_connections

#2Pool saturationdb.pool.wait_p95

checkout-apiinitial

#3Latency p99 breachhttp.server.duration.p99

orders-svcservice

#4Timeoutsrpc.client.timeouts

web-storefrontservice

#5Error rate spikehttp.server.5xx.rate

Causal Link DependencyClick an event to trace it · Click a service for detail

1payments-svckubernetesterminal
serviceConfig change0.3120
2payments-svcprometheus
servicePool saturation0.2440
3checkout-apiprometheus
serviceLatency p99 breach0.1620
4orders-svcopentelemetry
serviceTimeouts0.1180
5web-storefrontprometheus
serviceError rate spike0.0710

#1payments-svcConfig changekubernetesinspect evidence

service · config.pool.max_connections · Oct 19, 14:09:00

Scout

The pool on payments-svc was cut from 40 to 20 connections at 14:09. Pool waits climbed within two minutes, and every checkout and order call waits on that pool, so the change reaches customers in two hops.

40→20conns−50%

Why it ranks here

Score

0.3120

1.000 of the leader

Distance from entry

2 hops

from the initial entity

Historical frequency

0.04

prior for this event type

Upstream

terminal

nothing explains it

↖ Explained by (0)

Nothing upstream. This is a terminal cause.

↘ Explains (1)

payments-svcPool saturation#2

A smaller pool saturates under the same load · weight 0.9

Consequences this candidate explains 4 downstream events, through declared rules

web-storefrontError rate spike0.2→6.8%

Requests past the timeout budget surface as errors on the caller.

checkout-apiLatency p99 breach180→2600ms

A caller inherits the tail latency of the service it waits on.

payments-svcPool saturation12→1900ms

A smaller pool saturates under the same load.

Leading candidate payments-svcConfig change40→20conns

What explains this candidate

Nothing upstream. No declared rule leads into a config change.

Also explained by this candidate

orders-svcTimeoutsCalls that outlast the client timeout fail as timeouts.

#1payments-svc

config change

The pool was cut from 40 to 20 connections at 14:09. Every checkout and order call waits on it, so the change reaches customers in two hops.

Why it ranks here

#1rank0.3120score (raw pagerank)1share of top

Terminal (no upstream cause) yes

Access distance 2

Historical frequency 0.04

Causal links (declared rules)

causes payments-svc Pool saturation

A smaller pool saturates under the same load · pool_shrink_to_saturation · w 0.9

Where an incident's time goes

What's missing isn't more alerts.

It's knowing which one caused the incident.

The incident, on the clock

14:11

0 min in

Keep scrolling to run the clock

Today

14:11
The alert storm
Dozens of alerts fire at once
14:20
The war room
Six teams join one call
15:40
Manual digging
Logs, metrics, recent changes, one tool at a time
Next day
The RCA
The cause, written up after the fact

Every hour on the long line is downtime, engineers pulled off their work, and customers who noticed before you did.

With trufflerootstopped at 14:14

14:11
The same alerts
From the observability you already run
14:14
The top 3 root causes
Ranked, with the evidence for each. 95% top-3 accuracy.

Works with

Better than your favorite LLM.

The engine ranks candidate causes the same way on every run, so a result can be reproduced, replayed and checked, not argued with.

Deterministic
Better than your favorite LLM.
The engine ranks candidate causes the same way on every run, so a result can be reproduced, replayed and checked, not argued with.
Accurate
95% top-3 accuracy.
The true root cause is among the top three candidates, and every link to it cites the rule and the evidence behind it.
Fast
Answers before your coffee order is up.
The top 3 candidates in minutes, not hours. Your team starts from a short, ranked list instead of a blank page and a war room.
Yours
Built from how your systems fail.
The model comes from your topology, incidents, runbooks and code, so it knows how your services depend on each other instead of guessing. Your engineers review every rule, and every version is kept.
Learns
Better after every incident.
After each incident it finds what the model missed and proposes new events, rules and thresholds. Engineers approve them first.

Integrates with what you already run.

And learns from all of it.

truffleroot connects to your topology, telemetry, code and incident history. Each source either shapes the model or becomes evidence when something breaks.

Builds the model

Linear
Linear
Linear

Evidence for an investigation

Grafana
Prometheus
Datadog
Splunk
Sumo Logic
GitHub
GitLab
Bitbucket
Slack
Grafana
Prometheus
Datadog
Splunk
Sumo Logic
GitHub
GitLab
Bitbucket
Slack
Grafana
Prometheus
Datadog
Splunk
Sumo Logic
GitHub
GitLab
Bitbucket
Slack

Topology
Which services exist, where they run and what they call. The skeleton the causal model is built on.
Incident history
Past incidents, postmortems and runbooks: how your systems have failed before, and what your team learned.
Telemetry
The signals events are detected from, and the evidence cited when one event is linked to another.
Changes
Commits, merges and deploys, lined up against the timeline of the incident.
Your team
Start an investigation from the channel your team is already in, and get the explanation back in the thread.

Ask about your stack →

Try our demo.

A live environment you can explore on your own. The demo runs on Train-Ticket, an open microservice benchmark, set up the way a customer environment would be.

Try our demo

1
Open the demo
Nothing to install. The environment is already modelled.
2
Take the guided tour
A short walkthrough of triage, the causal graph and the explanation.
3
Work a live incident yourself
Open an incident, follow the causal chain to its root cause, and ask the investigation agent about it.

Find the root cause,from technical failures to business breakdowns.

What's missing isn't more alerts.

Why truffleroot?

Integrates with what you already run.

Topology

Incident history

Telemetry

Changes

Your team

Try our demo.

Open the demo

Take the guided tour

Work a live incident yourself