Critical Paths

Critical Paths is the first place to look. Rather than a list of slow spans, it finds the request paths through your system — a request entering at the frontend and fanning out through the services behind it — and ranks them by where the time and the errors actually accumulate. It is the default view atrim.ai opens on.

It lives under Intelligence → Critical Paths. It works on the same service graph as Service Topology; Topology is the full-system map, Critical Paths is the ranked findings-and-analysis view of it.

Note

This surface is meant to answer “what should I look at?” without you asking. It discovers and ranks on arrival — there is no service to pick first. Ranked paths appear as soon as your data does, with descriptive names and example traces attaching as analysis completes.

What you see

The left panel lists the discovered paths, ranked so the one most worth your attention is at the top. Each path shows:

• A name describing the flow (for example, the checkout path), written by analysis.
• A severity tag — critical, high, medium or low — derived statistically from the path’s own history, not a fixed threshold. Hover it for how the rank was reached.
• How many services the path traverses.
• Its numbers — request rate, P95 / P99 latency, and error rate — each with a small sparkline so you can see the trend, not just the current value.
• A short description of what the path is.

Staying current

You don’t refresh Critical Paths. Once it’s open, it keeps pace with your system on its own — as a new critical path arises in your live traffic it appears within a few minutes, and one that recovers drops away the same way, with no click and no picker. Leave it up on a wall display and it stays honest.

If your most recent traffic is older than the last hour — a quiet service that was last busy a few days ago — atrim.ai widens the window to where your paths actually are, and tells you it did.

Note

atrim.ai picks the window that shows you your paths, so this surface needs no time-range control. When you do want to drive the range yourself, that’s what Service Topology is for.

Following a finding to its evidence

• Select a path to focus it. Its services light up on the topology map beside the list, and the Explore panel on the right keys to it.
• View Trace opens an example trace that exhibits the path — the concrete request behind the ranking, one click from the finding.
• Analyze runs the atrim.ai analysis agent over that trace to name the hop that dominates and lay out the evidence for it.
• From the Explore panel you can open the path’s scope directly in Traces, Logs or Metric Explorer when you want the raw requests, lines or metrics behind it.

You can select more than one path at a time (⌘/Ctrl-click) to compare them on the map, and filter the list — by search, or to Critical only, High errors or Slow paths.

Tip

Three analysis modes sit at the top of the panel. Cross-Service (the default) ranks paths that cross service boundaries. In-Service focuses within a single service and its callers. LLM ranks GenAI/model call paths for AI-heavy workloads.

Read-only by design

Critical Paths surfaces and explains. Running the analysis agent over a trace is a read-only explanation of your own data — nothing atrim.ai does here reaches into your infrastructure or holds your credentials.

Service TopologyThe full-system map behind these findings — every service and call, with rate, error and duration.

IncidentsWhen a condition is worth telling someone about, the detect → notify → resolve loop takes over.