Read the issue
The customer's words, the account, the reference numbers and the timing.
Every customer issue, investigated to the root cause.
TraceX picks up the issue where it starts, investigates your production systems read-only, and comes back with the root cause, the evidence, the fix and the reply.
M
Maria Chen · to support · 9:41
My refund from last week still hasn't arrived. Order #48213.
Intake
Triage
Evidence
Root cause
Action
Resolve
Reading the email…Checking database…Reading the code…Checking Sentry…Root cause found
PostgreSQL 34 refunds with state = 'pending' since Oct 21
GitHub Migration 0142 renamed pending → awaiting_payout
Sentry No errors: the worker finds nothing to process
Live traceread-only
Read the emailorder #48213 · refund
Planned 4 checksdata · code · errors · logs
SELECT state FROM refunds WHERE order_id = 48213'pending'Searched code for the refund filterrefunds.py:42
Read 3 recent commits7f3b10 renamed the state
Checked Sentry · refund-worker0 errors
Tested: the worker skips the renamed stateconfirmed
Root cause refund worker
Migration 0142 renamed the refund state,but refunds.py still filters on pending.
Confidence93%
ExpectedRefunds move to the payout queue within an hour.
ActualThe worker filters on
pending, which no longer exists.Reply drafted
Hi Maria, we found the problem and your refund is on its way.
The journey
Six steps, every one visible.
Plan the checks
Which tables, repositories and logs can answer it, and in what order.
Collect evidence
Read-only queries, code and recent commits, Sentry issues and log events.
Prove the cause
A root cause with its confidence, tested against the evidence; rejected ideas are kept too.
Write the fix
The change, its risk, and how to validate it, ready to open as a pull request.
Close the loop
A reply for the customer, and a record your team can learn from next time.
Root cause
Not a guess. A cause you can check.
Each investigation states what should happen, what actually happens, and why, and links every claim to the record, file or log line it came from.
- Confidence for every root cause
- Expected versus actual behaviour
- Evidence you can open: rows, code and log lines
PostgreSQL 34 refunds with state = 'pending' since Oct 21
GitHub Migration 0142 renamed pending → awaiting_payout
Sentry No errors: the worker finds nothing to process
Root cause refund worker
Migration 0142 renamed the refund state,but refunds.py still filters on pending.
Confidence93%
ExpectedRefunds move to the payout queue within an hour.
ActualThe worker filters on
pending, which no longer exists.The fix
From diagnosis to pull request.
TraceX writes the smallest change that fixes the root cause, checks it against your code, and opens the pull request when you say so.
- A reviewed diff with its risk level
- Validation steps for your team
- Opened as a pull request, or as a draft
app/workers/refunds.py+1 −1
def pending_refunds(db):
− return db.refunds.filter(state="pending")
+ return db.refunds.filter(state="awaiting_payout")
Validate run the refund worker against staging; 34 refunds move to payout
Where it starts
It works where your issues arrive.
Connect your support inbox and TraceX starts an investigation from each new customer email. Ask in Slack, from a Jira ticket, or start one in the dashboard.
- Gmail support inbox, read-only
- Slack and Jira
- A reply drafted for the customer
Maria Chen
InvestigatingRefund still not received, order #48213
#support
InvestigatingA customer was charged twice for one order
SUP-212
InvestigatingCheckout times out on Safari
Hypotheses
Every idea tested. The wrong ones too.
TraceX doesn't stop at the first plausible answer. It lists what could explain the issue, checks each one against the evidence, and keeps the ones it ruled out, so you can see why.
- Each hypothesis checked against data, code and logs
- Ruled-out ideas kept, with the evidence that ruled them out
- Confidence on the one that holds
Hypotheses3 tested
The payment provider rejected the refundThe provider has no refund request for #48213
Ruled outThe refund worker crashedSentry shows 0 errors in refund-worker
Ruled outThe worker skips the refund's stateIt filters on 'pending', which migration 0142 renamed
ConfirmedTimeline
What happened, in order.
Every investigation lines up the deploys, errors and messages around the issue on one timeline, so the story is clear at a glance.
- Deploys and commits from GitHub
- Errors and log events from your monitoring
- The customer's own messages, in context
Oct 21 · 10:02Migration 0142 deployed
Renamed the refund state pending → awaiting_payout
Oct 21 · 10:03Refunds stop moving
The worker finds 0 refunds to process, every minute
Oct 28 · 09:41Maria writes in
“My refund from last week still hasn't arrived.”
Oct 28 · 09:47Root cause found
93% confidence, with the evidence for each step
Oct 28 · 09:52Fix opened
Pull request #318, ready for review
FAQ
Investigation questions.
What does TraceX need to start an investigation?
A connected database and repository are enough to begin. Each extra source, such as Sentry, Datadog, CloudWatch or your support inbox, gives it more evidence to work with.
Can it change anything in production?
No. Databases are connected with read-only credentials and every query is checked before it runs. Fixes are offered as pull requests for your team to review.
What if TraceX can't find the cause?
It says so, and shows what it checked and what it ruled out, so whoever picks it up next doesn't start from scratch.
Where do investigations start?
From a support email, a Slack message, a Jira ticket, or a question in the dashboard or the CLI.
Find the root cause.
Ship the fix.
TraceX is free during the private beta. Connect a database and a repository and ask your first question in minutes.