TraceX

TraceX is an AI engineer for production issues, built to take a customer-reported problem from the first support message all the way to a proven root cause and a fix. When a support email, a Slack message, a Jira ticket or a question in the dashboard arrives, TraceX reads it, plans what to check, and then investigates the systems behind the issue: it queries the database read-only, reads the code and recent changes, and checks error and log tools such as Sentry, Datadog and CloudWatch. It then returns the root cause with a confidence level, what should have happened versus what actually happened, and the evidence behind every claim. From there it writes the fix as a pull request and drafts a reply for the customer. It is aimed at engineering and support teams running production software, and it is free while in private beta. The hard part of a production issue is usually not the fix but finding the cause. A customer writes that a refund has not arrived, and the explanation can be buried across a database state, a migration that renamed something weeks earlier, a code path that still filters on the old value, and a background worker that now finds nothing to process. In the example shown on the TraceX site, 34 refunds sit in a pending state created after October 21, migration 0142 renamed pending to awaiting_payout, and the refund worker still filters on pending, so it silently finds nothing to process. Sentry reports no errors at all, because nothing crashes; the worker simply has nothing to do. Tracing that by hand means jumping between a database console, a repository, a commit history and log tools, and then explaining the conclusion to a support team and to a customer. TraceX is built to do that work in one place, the way your best engineer would, and to show its work at every step so the answer can be trusted rather than guessed at. Every investigation moves through six visible steps: intake, triage, evidence, root cause, action and resolve. Intake accepts an issue from a support email, a Slack message, a Jira ticket or a question in the dashboard. TraceX then plans its checks and follows the data and the code until the cause is clear, querying PostgreSQL, MySQL or MongoDB through read-only credentials, reading the code and recent commits through the GitHub App, and checking Sentry, Datadog and CloudWatch. The result is a root cause presented with its confidence level, an expected-versus-actual comparison, and a citation for every finding pointing to the record, code or log line behind it. A second model checks the answer against that evidence, which is how TraceX keeps answers grounded in what it actually looked up rather than in plausible-sounding assumptions. From the root cause, TraceX moves to action. It writes the smallest change that fixes the cause and opens it as a pull request, with the diff reviewed and its risk level shown, along with validation steps written into the description. In the refund example, the fix changes a single filter from state="pending" to state="awaiting_payout" and is presented as low risk, with the validation step of running the refund worker against staging so that 34 refunds move to payout. TraceX also reviews your team's pull requests, giving reviews on every PR with one-click suggestions. Alongside the code fix, it drafts a reply for the customer, so the support conversation can close with an accurate answer instead of an apology and a promise to look into it. TraceX also answers questions about your systems in plain English: how many refunds are stuck, which customers were charged twice, or what changed in checkout since Monday. Answers come from your databases, code and logs rather than guesswork, each step is shown as it happens, and each claim is cited. When a longer answer is needed, TraceX produces spreadsheets, CSV and PDF exports. In the example conversation on the site, asking how many refunds are stuck returns 34 rows in the pending state, all created after migration 0142 shipped, with the query, the commits read and the verification against the evidence all displayed. This turns ad hoc production questions into documented, checkable answers that a support lead or engineer can act on immediately. For developers who prefer the terminal, the TraceX CLI brings the same capability into your repo. You sign in through your browser, link a repository with one command, and ask TraceX from your terminal with tracex -c for answers carrying the same evidence as the dashboard. It installs with one line on macOS and Linux. In a linked repository it also works in a coding mode that reads, edits and runs tests, asking for your approval before every change and command. The site shows the flow in practice: it edits app/workers/refunds.py, shows the removed and added filter lines, asks whether to apply the change, then asks whether to run pytest, and reports 12 tests passed. In a repository that is not linked, TraceX works as a coding agent that asks before every change. The design of the product is centred on trust. TraceX connects to your databases with read-only access and runs only read-only queries, so nothing in production is changed, and the site lists production writes at zero. Access is read-only and can be revoked at any time. Your records are not kept: there is no index of your code or data, answers retain what was looked up and where rather than the rows themselves, and exported files are deleted after 24 hours. You approve every change, because fixes arrive as pull requests for your review and the CLI asks before every edit and command. Enterprise sign-in covers SSO, two-factor sign-in, roles for admins, investigators and viewers, revocable sessions and a full audit log. You can also run TraceX on your own Anthropic or Gemini account, so AI usage is billed to you and never through TraceX. The outcome is that every customer issue can be traced to its root cause with evidence attached. Instead of an engineer spending time reproducing a report and correlating tools, TraceX returns a root cause, a confidence level and an expected-versus-actual comparison that a team can check line by line. Support gets a drafted reply built from the actual finding, engineering gets a reviewed pull request with validation steps, and the answer can be verified against the cited records, code and log lines. Because every finding cites its source and a second model checks the answer, the conclusion stands on evidence rather than on a model's best guess, which matters when the output is going to a customer and into production code. The product fits concrete day-to-day workflows. A support email saying a refund has not arrived starts an investigation that ends with a root cause and a reply ready to send. A teammate mentions TraceX in a Slack support thread asking why an order was charged twice, and gets the answer, with its evidence, right there in the thread. A Jira ticket about checkout timing out on Safari comes back with a comment explaining the root cause and a linked pull request. A support lead asks in plain English how many refunds are stuck and since when, and receives the rows, the commits read and the verification behind the number. A developer uses the CLI to fix the refund worker filter and run the tests. Teams also use TraceX to review the pull requests they open themselves. TraceX is in private beta with early engineering teams and is free while in beta, with 50 investigations a month during the private beta. It connects to 10 integrations — PostgreSQL, MySQL, MongoDB, GitHub, Sentry, Datadog, CloudWatch, Gmail, Slack and Jira — covering databases, code, logs and inboxes, all connected read-only. Setup is described as connecting a database and a repository and asking your first question in minutes, with an early access request and a sandbox available to try. The combination of read-only access, cited evidence, human-approved changes and the option to bring your own model keys makes it usable for teams that need to see exactly what the system looked at before they act on its conclusions. In short, TraceX's value proposition is simple: every customer issue, traced to the root cause. It reads the support email, investigates the database, logs and code read-only, proves the cause with cited evidence and confidence, writes the fix as a pull request and drafts the customer reply, while keeping production untouched and every change under your approval.