Read a report
The parts of a TraceX investigation report, the summary, root cause, confidence, evidence, fix and customer reply, and how to confirm or correct it.
When an investigation finishes, its page shows the report. It is written for two readers at once: the engineer who will fix the problem, and the person who reported it and wants to know what happened. This page walks through each part.
The diagnosis
Section titled “The diagnosis”| Part | What it tells you |
|---|---|
| Summary | The problem and its cause in two or three plain sentences. Read this first. |
| Root cause | What is wrong, where it is (table, file and line, service) and why it produces the symptom. |
| Confidence | How sure TraceX is, and what would raise it. |
| Impact | Who or what is affected and since when, measured from your data where possible. |
| Ruled out | The other explanations TraceX checked and why they don’t fit. |
How to read confidence
Section titled “How to read confidence”Confidence is shown as a percentage, for example Confidence 86%. It reflects how directly the evidence supports the root cause:
- High (an error whose stack trace names the changed line, plus records that show the effect): the evidence points straight at the cause.
- Middling: the cause is the best explanation, but a link is inferred rather than seen.
- Low: TraceX has a lead, not an answer. The report says what it would need to be sure, such as a log source or an identifier.
When two causes fit
Section titled “When two causes fit”Sometimes another explanation is supported nearly as well. The report then shows the competing cause with how well it is supported, lowers its confidence, and does not draft a fix. Compare both before acting. Findings that don’t fit the root cause are listed too, because they are what lowered the confidence.
The evidence
Section titled “The evidence”Each finding links to what supports it: the database query and its rows, log lines, Sentry errors, the code, and the commit or pull request that introduced the problem. Open any piece of evidence to see exactly what TraceX saw.
Raw evidence stays in the dashboard and is never put in a shared link.
The fix
Section titled “The fix”When the root cause is grounded, the report includes:
- the change: a code patch, a data correction or a configuration change,
- why it fixes the problem,
- its risk (low, medium or high),
- how to check it worked, such as a query to run or a behaviour to confirm.
From here you can open a pull request. See Fixes and pull requests.
For the people who reported it
Section titled “For the people who reported it”- Suggested customer reply: a reply your support team can send as is, in plain language and without internal detail.
- Engineering note: a short handover for the team that owns the system.
Confirm or correct the root cause
Section titled “Confirm or correct the root cause”At the bottom of a finished investigation, tell TraceX whether the root cause was right. This takes a few seconds and matters:
- Confirmed root causes count towards your accuracy in Reports and accuracy.
- Corrections become facts TraceX uses in later investigations, so the same mistake isn’t repeated (organizational memory on the Team plan).