The ticket says what broke. Crumbtrail says why.
A customer reports a wrong payout. Crumbtrail has already recorded the session they ran, the request it sent, the backend span that served it and the database row that changed, all carrying one key, and hands your coding agent the evidence and a ranked opinion on which class of fix this actually is.
The problem
Why an agent proposes the first plausible fix
A ticket says the payout was wrong. What explains it sits in four systems that share no common key: the browser session, the request log, the backend trace, and the row that changed. An agent handed only the ticket text answers from the ticket text, so it proposes the first plausible fix rather than the correct one.
Most of these failures never raise an error either. A count that disagrees with the rows it changed. An export that answers 200 OK with an empty body. A write that quietly emptied a column. All of them look healthy from the network tab, so nothing pages anyone and the ticket is the first signal anybody gets.
The seam
One join key, stamped at capture. We call it the crumb.
It is the reason the brief can be assembled at all, and the one thing a browser only tool cannot do by construction.
The crumb is written while the failure is happening, using injected W3C trace context, not reconstructed from timestamps afterwards. The click carries it, the network call carries it, the backend span carries it, and so does the row that changed. By the time anyone opens the ticket, the four systems already line up.
A tool that lives in the browser can show you the click and the request. It cannot put its key on the write, because it was never in the process that made it. That is not a feature gap that closes with more effort. Everything else on this page rests on the crumb.
The product
What your agent receives
Complete evidence, and a separate ranked opinion on which class of fix this is. The evidence is stored apart from the opinion, so an agent can read the facts without reading our conclusion first.
Everything the failure touched
Interface steps, console output, network calls with headers and bodies, backend request spans, column level database row diffs, and the code the write came from. All of it carrying the same crumb.
Ranked across fix classes
Regression, data, infrastructure or configuration, client side, or an intentional change behaving as designed. Naming the class is the point: an agent that assumes every ticket is a code bug writes code for a problem that lives in a setting.
What happened last time
Issues are canonical across sessions and releases, so a brief can tell your agent this arrived three days ago, or that it was fixed seven months back and the workaround did not hold. A ticket matching an issue already under investigation attaches to it instead of forking a second line of work.
Whether the last fix held
After a fix ships, an observation window opens on the issue. Only a terminal verified verdict counts as held, and anything short of that is reported as unresolved rather than quietly closed.
The opinion is advisory and it never gates anything. When the evidence cannot support a conclusion the brief says so and ships the evidence anyway, because a confident guess presented as a finding is the failure this product exists to remove.
The loop
No workflow step in the middle
If a person has to click something in our interface for the pipeline to run, we designed it wrong.
Capture runs first
Sessions and backend events are recorded before any ticket exists. Evidence cannot be attached to a failure after the fact, which is why this runs continuously rather than on demand.
The ticket finds its session
Crumbtrail reads the new ticket from your tracker over a verified webhook, matches its symptoms against captured evidence, and locates the incident window.
One brief is assembled
Interface steps, logs, network calls, row diffs and code, gathered into a single bundle for that issue, with the advisory opinion attached beside the evidence rather than mixed into it.
Your agent reads it
Either the brief link arrives as a comment on the ticket, or your developer pastes the ticket reference into their agent and it resolves the bundle itself. Both paths end at the same evidence over MCP.
The dial
You set how far it goes
One pipeline, three settings, and the setting is always yours.
Detect and alert
Silent failure detectors report that a number of people hit the same thing, with a ranked causal window and a repro hint. Rage clicks, retry storms, slow responses, abandoned flows. This feeds capture rather than being the reason to buy.
Ticket to brief to agent
The default setting, and the one this page is about. A ticket arrives, a brief is assembled, your agent reads it. Nothing is written to your codebase and nothing waits on a person.
Draft the fix
Crumbtrail generates a patch grounded in your indexed repository and opens at most one pull request per suggested fix, each on its own branch, so regenerating a fix gives you a second pull request to compare rather than replacing the first. It is off by default and stays off until you turn it on, it needs the model and repository connections wired up, and it runs under a spend cap, a confidence bar and a daily limit you set.
Your tracker stays the system of record throughout. It owns assignee, status and service level. Crumbtrail mirrors that state and owns the evidence instead, so nobody has a second queue to work.
What feeds it
What feeds it
Run our capture, bring your own telemetry, or both. We never ask you to duplicate a service you already pay for, and we never need one of them to be useful on our own.
Database row diffs
Column level before and after for every write, correlated to the request that caused it, across Postgres, MySQL, SQL Server and SQLite. A write can carry the application callsite that issued it, so a diff names the handler a fix has to touch rather than the shared repository helper.
Backend request lifecycle
Request start, request end and server errors, joined to the browser call that triggered them by the crumb rather than by matching timestamps. Queues, cron, retries and webhook fan out report against the request that enqueued them.
Browser session
Console output, uncaught errors, network calls with headers and bodies, clicks and keystrokes, storage and cookie changes, WebSocket frames both ways, server sent events, worker messages, and a masked snapshot of the page at flag time.
Silent failures
A response count that disagrees with the rows the same request changed. A retry loop running against a success response. An update that emptied a column the request never named. None of these raise an error, so none of them reach an error tracker.
OpenTelemetry with no SDK
Traces and logs arrive directly over OTLP in JSON and protobuf, joined to the owning session through a durable trace join store. A team already exporting installs nothing at all.
Privacy first
By default, the browser SDK masks text nodes, keystrokes, and form values in page snapshots before capture. Input events use the same deny biased redaction policy as request payloads, so ordinary numbers and short codes may be recorded. You can explicitly unmask one element or block an element and its contents. Global Privacy Control is respected, and retention follows your plan.
Your tracker and your telemetry are inputs, not rivals
Jira connects over OAuth 3LO and is the deepest integration: verified webhooks, brief assembly, issue mirroring, ticket history read into issue memory, and advisory comments. OpenTelemetry arrives directly over OTLP. GitHub connects as an app install rather than a pasted secret, and Slack carries the support threads about a failure that never became a ticket.
Jira, OpenTelemetry and Sentry are verified against published schemas. Splunk, PostHog and Cloudflare are matched by discovery and tenant review rather than certified, and Datadog publishes its endpoint as an unstable preview.
Crumbtrail Cloud
Try it before you talk to us
This command is Crumbtrail Cloud. The four SDK packages use MIT and are published to npm. The installer uses PolyForm Shield and is free to read and run. It takes a few minutes, so you can run this against a real bug tonight.
npx crumbtrailRun it from your app's root. The wizard signs you in, creates the project, installs the SDK, and waits for your first event. If the dashboard Setup page already showed you `--endpoint` and `--project`, that is the same command with your project filled in.
No card to start
The 14 day trial takes an email address. Capture, correlation, the silent failure detectors and MCP retrieval are all available on it.
MIT licensed SDKs, published today
The browser SDK has zero dependencies. Read the source before you ship it, which is most of the point of shipping it this way.
Your agent reads it over MCP
The cloud speaks MCP directly, and the same tools run locally over stdio. Most tools read evidence. The write tools update Crumbtrail's own stores, with feedback and resolution feeding its learning loop. requestProbe also queues a named probe that a live visitor's browser runs. Live probes are on by default until you turn them off in Capture settings.
See it on your own tickets
Bring your tracker and your telemetry, and we will show you what correlates.