Root cause analysis on the running service
InSitu is an AI on-call agent. When logs and traces do not explain a failure, it places a read-only probe on the failing line of live code and captures the state that was never recorded. Nothing is redeployed.
Book a working session on a live incident
What is root cause analysis in production?
Root cause analysis in production is proving why a live service failed, using evidence from the running system. Tools that reason over stored logs, traces and metrics return a probable cause, limited to what was recorded before the failure. InSitu captures the variable state at the failing line on live traffic, then checks the diagnosis against that capture. The output is a confirmed root cause.
InSitu reads the existing logs and traces first, and places a probe only when that data does not explain the failure. A probe is a read-only, non-blocking virtual breakpoint, so the service keeps serving traffic while the evidence is collected. Because the cause is verified against captured state before it is handed back, the fix addresses why the incident happened rather than a symptom of it.
Why do logs miss the cause?
Logs hold only what someone chose to record in advance, and traces do not carry response bodies. When the explaining value was never logged, the usual next step is to add a log line, redeploy and wait for the failure to recur. Teams often repeat that cycle two or three times, and each cycle costs 30 minutes to two hours while the incident stays open. Adding a log line only works if the engineer already guessed the right line.
Each redeploy is a change to a live system, made under pressure, to collect information the running process already holds. On a transaction path, every minute the incident stays open costs revenue or customer trust. The redeploy loop fails outright when a bug fires for one user, with data that cannot be rebuilt on a local machine. The same loop fails on silent failures, where the request returns a 200 and no exception or alert is raised. A probe reads the missing value from the running service on the next matching request, with no code change.
Silent 200 responses
The request returns 200 with the wrong body. Nothing throws and nothing pages anyone. A probe reads the computed value before it is returned.
Values never logged
The variable that explains the failure was never written to a log. A probe captures it from the running process with no code change.
Exceptions far from cause
The stack trace names where an exception surfaced. A probe sits where the bad value was set, several frames earlier.
Race conditions
Two operations overlap in time. A conditional probe captures what each request read at the moment of overlap.
Third-party contract drift
A partner sends a new status value or response shape. A probe on the parsing code shows the value as it arrives.
Failures for one user
One account fails and every other works. A probe scoped to that user ID captures the state and leaves other traffic untouched.
How does InSitu find a root cause?
InSitu works from alert to confirmed cause in five steps.
1. Alert:
it receives the page from PagerDuty, Datadog or Slack.
2. Plan:
it reads existing logs and traces and locates the suspect file and line.
3. Probe
: only if that data does not explain the failure, it places a read-only probe on the line, with no redeploy.
4. Capture:
the probe fires on the next live request and records the exact variable state.
5. Confirm:
the diagnosis is checked against the capture, and the engineer commits the fix.
The flow runs through the InSitu MCP server inside the coding agent an engineer already uses, such as Cursor, Claude Code, Codex or opencode, or from VS Code by right-clicking an executable line. The service keeps serving traffic through every step, and no thread pauses while the probe waits to fire. InSitu does not open a pull request or ship a change, so production stays under the team's control.
What does a probe capture?
A probe is a read-only breakpoint on one line of running code that never pauses execution. When the line runs, the probe captures local variables, the call stack, reachable heap state and the triggering request, then sends the copy out of the process. The capture is scoped to that one line and that one moment, so a probe never streams data continuously. A probe cannot capture a value from a line it was not placed on, and it cannot look back at a request that completed before it was set.
InSitu measured under 1% CPU overhead at 3,000 requests per second, with about 50MB of memory and no measurable added latency. PII redaction runs at the agent by default on every plan, so sensitive fields are redacted before a capture leaves the service. The captured state goes back to the coding agent or the VS Code sidebar, where the diagnosis is checked against it. That state is the data that was never in the logs: the value the code actually computed at the moment of failure.
How is a probe kept bounded?
Every probe clears itself on three limits set by the engineer who places it: a time to live, a rate limit and a hit expiry. A condition scopes a probe to one user, request or value, so other traffic is not captured. A probe cannot write memory, call functions or change control flow, and this is enforced in the architecture. On the Enterprise plan, a security team sets organization-level ceilings on all three limits.
A time to live means a forgotten probe cannot stay armed, since it clears when the window closes whether or not it fired. A rate limit keeps a probe on a high-traffic line from generating excessive captures. A hit expiry stops collection after a set number of captures, such as five matching examples for a webhook bug. On Enterprise, an approval gate can require a second person to sign off before a probe arms. Every probe placement and capture is written to an immutable audit log.
What changes on a hard incident
Under 10 min
Time to confirmed root cause, down from 3 to 4 hours
0
Diagnostic redeploys per incident, down from 3 to 4
0
Senior engineers pulled in, down from 2 to 3
15 min
Typical setup, SDK install to first capture
How long does setup take?
Setup is typically finished within fifteen minutes, from installing the SDK to capturing the first live variable. From a coding agent, one install prompt adds the SDK, wires the entrypoint, turns on source maps and registers the MCP server. A manual install uses a package manager for Node.js and TypeScript, or a Java agent JAR attached at JVM startup.
InSitu supports Node.js, TypeScript, Java, Kotlin, and Python. Go, Ruby, and Bun are not supported today, so a team running a mixed stack can instrument its supported services now and leave the rest until support ships. The Free plan covers one service on managed cloud with unlimited probes and captures, and moving to self-hosted later does not require reinstalling the SDK.
Frequently Asked Questions
How does AI root cause analysis work?
AI root cause analysis tools read logs, traces, metrics and recent changes, then rank probable causes. InSitu starts the same way. When that data does not explain the failure, InSitu places a probe on the suspect line, captures the missing state and confirms the cause against it.
What should a production root cause analysis tool do?
A production root cause analysis tool should explain failures that left no trace in existing telemetry, show the evidence behind each conclusion, and stay safe on live traffic. InSitu does this through live capture, diagnosis checked against captured state, and read-only probes that clear themselves.
What is the difference between correlation and a confirmed root cause?
Correlation shows that two signals moved together. A confirmed root cause is checked against the state that produced the failure. InSitu confirms against the variable values captured at the failing line.
Does InSitu replace existing observability tools?
No, InSitu does not replace existing observability tools. On an alert, InSitu reads the logs and traces a team already collects, then places a probe only where that data does not explain the failure.
What is the difference between a probe and a breakpoint?
A probe never pauses execution, and a traditional breakpoint does. The request that hits a probed line completes on its normal path while the probe copies the state.
What happens to sensitive data in a capture?
PII redaction runs by default on every plan, at the agent, before a captured value leaves the service. Every probe placement and capture is written to an immutable audit log. Self-hosted and private VPC deployment are available on request for Professional and included on Enterprise.
Can InSitu diagnose an incident that already ended?
No, a probe cannot recover a moment that already passed. A probe captures a line only after it is placed, so it catches the same condition the next time it happens.
Does InSitu fix the bug automatically?
No, InSitu does not commit a fix or open a pull request. The agent confirms the cause against captured evidence, and the engineer commits the fix.
Which languages does InSitu support?
InSitu supports Node.js, TypeScript, Java, Kotlin, and Python. Go, Ruby, and Bun are not supported today.
How is InSitu priced?
InSitu is priced per service, not per engineer or per seat, with unlimited probes and captures on every plan. The Free plan covers one service. Professional costs $99 per service per month, or $79 per service per month billed annually, with a three service minimum.
Bring a live incident. Leave with its root cause.