Root cause in 60 seconds: how ArcIn traverses 40 services to find the answer

The problem with traditional incident response

When an incident fires at 2am, the on-call engineer opens five dashboards, joins a bridge call with three colleagues, and spends 45 minutes correlating metrics across services before someone finally says "I think it's the database." Then someone else spends another 20 minutes confirming it.

This is not a people problem. This is a tooling problem. Your monitoring tools were built to show you data — not to answer questions.

ArcIn was built to answer questions. Here's how it traverses 40+ services in under 60 seconds to find the root cause of any incident.

The entity graph — ArcIn's foundation

ArcIn doesn't analyse services in isolation. It operates on the causal entity graph — a continuously updated model of your entire infrastructure that maps causal relationships between every service, host, database, and cloud resource in your environment.

When ArcIn receives a question like "why is checkout-svc slow?", it doesn't just look at checkout-svc's metrics. It traverses the graph upstream and downstream, looking for the entity whose degradation best explains the symptom.

The traversal algorithm — simplified

ArcIn's traversal works in three stages:

1. Symptom identification — identify the entity experiencing the reported degradation and the exact metric that changed
2. Causal graph traversal — walk upstream through the dependency graph, scoring each entity by its probability of being the root cause based on timing correlation, magnitude of change, and historical patterns
3. Root cause synthesis — identify the highest-probability root cause, retrieve the specific event (deploy, config change, traffic surge) that triggered it, and generate a plain-English explanation with a recommended fix

A real example: the checkout incident

At 14:32 on a Tuesday, checkout-svc p99 latency increased from 180ms to 520ms. ArcIn traversed the graph and returned this analysis in 47 seconds:

The on-call engineer received this in a Slack message before they'd even opened a dashboard. Total resolution time: 11 minutes (including the rollback verification).

Why plain English matters

ArcIn deliberately outputs its analysis in plain English rather than raw metrics. This isn't just a UX decision — it reflects a fundamental belief that observability tools should serve engineers at every skill level, not just the ones who know how to read flame graphs.

When a developer can ask "why is my service slow?" and get a specific, actionable answer in under a minute, the conversation about incident response changes completely.