How TraceX works

TraceX is an investigation engine for production issues. You describe a problem, or it arrives on its own from Slack, email, a ticket or an alert, and TraceX investigates it across everything you connected to that project. This page explains what it does at each step, so you know what to expect from a report and why you can trust it.

The problem TraceX solves

When something breaks in production, the information you need is spread across several systems. The symptom is in a support ticket. The failing requests are in the logs. The exception is in Sentry. The affected records are in the database. The cause is in a commit that shipped an hour ago. Lining all of that up by hand takes an engineer who knows every system, and it takes time while customers wait.

TraceX does that lining up for you, the same way every time, and shows its work.

One investigation: evidence from every connected system flows in, one grounded root cause comes out.

The four steps of an investigation

1. Triage

TraceX reads the issue and works out what kind of problem it is: bad or missing data, a code bug, a recent change, or an outside service failing. It pulls out the identifiers it can search for, such as order numbers, emails, request ids and error messages, and the time the problem started. It also checks whether the same problem is already being investigated, and links duplicates instead of starting again.

2. Evidence

Then it collects evidence from the sources the problem points to:

• Databases: read-only queries for the records involved, such as the order, the customer, the payment and the rows around them.
• Logs: searches around the time the problem started and for the identifiers in the issue. Log lines are grouped into patterns with counts, errors first, so a burst of the same failure stands out.
• Errors: the matching exceptions, their stack traces and their releases.
• Code: the files and functions the errors point to, read from your repositories.
• Changes: the deploys, commits and pull requests that shipped just before.
• Your knowledge: runbooks, docs and facts in your knowledge base and company profile.

You can watch this happen live on the investigation page.

3. Diagnosis

TraceX forms a hypothesis, tests it against the evidence, and rules out the alternatives. The report says how confident it is, what supports the conclusion, and what it checked and rejected. If the evidence isn’t enough, it says so and names what would help, such as a missing log source or an identifier to look up, rather than guessing.

4. Fix

When the root cause is grounded in your code or data, TraceX drafts the fix. That can be a code change, a data correction or a configuration change, with its risk and how to verify it. You decide whether it becomes a pull request. See Fixes and pull requests.

Which change caused it

Many incidents start right after something ships. For an incident that began at a specific time, TraceX ranks the changes that shipped just before it:

• the commits between the last two deploys, from GitHub Deployments and Releases, or
• without deploy records, the commits merged in the hours before.

Each suspect comes with its reason: files the error names, functions it changed, words it shares with the error. You can ask for this list directly with the suspect_changes tool in your AI coding tool.

For an incident that started at a known time, TraceX ranks the changes that shipped just before it.

What makes an answer trustworthy

• Every claim cites evidence: the query and its result, the log line, the error, the file and line, the commit. Nothing is stated without a source.
• What was ruled out is listed, so you can see how far TraceX looked.
• Confidence is explicit. A weak answer looks weak.
• Your corrections stick. When your team corrects a root cause, TraceX remembers it for the organization. See Reports and accuracy.

Safety by design

TraceX is built to be safe to point at production:

• Database connections are read-only. Every generated query is checked and refused unless it is a single read-only SELECT. Queries run in read-only transactions with row and time limits.
• Secrets are masked before anything is sent to an AI model, and personal data can be hidden too. See Data controls.
• Every query, log search and file read is recorded in the data access log.

Every query TraceX writes is checked before it runs. Only a single read-only statement passes.

Questions as well as incidents

The same engine answers everyday questions in Conversations, Slack, the CLI and AI coding tools. Questions use the same sources and the same safety rules; they just stop at an answer instead of a full report.