crumbtrail Request early access
Early access

Match production on your machine.

Crumbtrail records each failing request with the rows, cache keys and outside calls it touched. Then it rebuilds exactly that state on your machine, so your real code fails the same way it did in production. It brings only the rows that request touched, so you skip the production restore.

Request early access See how it works
For engineering and support teams chasing bugs that only happen in production.

Example output.

The problem

Production bugs depend on production data.

The customer's rows, the cache state, the outside service that answered oddly. Your machine has none of it. The bug won't happen there, so every fix is a guess.

Without Crumbtrail
  • Ask the customer for steps you'll never get exactly right.
  • Restore a copy of production for hours to chase one bug.
  • Guess at the rows that were in the database when it broke.
  • Ship a patch because the error stopped.
With Crumbtrail
  • The failing request is already recorded, with the rows and outside calls it touched.
  • Your machine gets just those rows, ready to run.
  • It fails the same way 10 times out of 10 before anyone writes a fix.
  • Run the patch against the same state and see whether the failure is gone.
How it works

Four steps from a customer report to a bug you can run.

A real recording from our test app, checked in the Crumbtrail dashboard. Under a minute, with sound.
Read the transcript

Your AI coding agent says it fixed a production bug. Here's how Crumbtrail verifies that fix.

Crumbtrail recorded this failing request in our test shop, and saved the database rows behind it.

Then it replays the bug on your real code, sealed off from production. It fails the same way every time: same status, same error, same line of code.

The agent's fix is on a branch. We run the original code and the fix, ten times each, against the same recording.

The original fails every time. The fix never does.

Every database read the fix made came from the recording. So Crumbtrail calls it: fixed.

Copy the summary into your ticket, and move on.

  1. 01

    Record

    Add the recorder to your start command. It saves each failing request with the database rows and outside calls it touched.

    loads from your start command
  2. 02

    Reproduce

    Crumbtrail rebuilds production's state for that request in a throwaway database on your machine, cut off from every live system. Your real code must fail the same way 10 times out of 10.

    same status, error type, database error and code line
  3. 03

    Hand off

    Give the recording to a developer or a coding agent. They run the production failure on their own machine as often as they need.

    any coding agent or a person
  4. 04

    Check the fix

    The patched build runs from the same production state. The runs decide the result: fixed, still broken or could not tell.

    report names the exact recording and build
Setup · two commands
# set up the recorder in your app. no changes to your code. shows the database settings it needs.
$ crumbtrail install

# one time, with your database owner's OK: turns on logical replication. needs a direct connection, not a pooler.
$ crumbtrail install --apply-db
Then check the fix

"Could not tell" is a real answer.

Crumbtrail checks a patch only against the state it recorded. If the patch reads data the recording never saw, Crumbtrail names what's missing instead of guessing.

Fixed

The recorded failure is gone on all 10 runs, and every database answer the patch relied on came from recorded data.

Still broken

The same failure comes back, or a new one appears. You see which, and where in your code.

?Could not tell

The error went away, but the patch read rows the recording didn't capture. You get the list of what it couldn't check.

10/10A bug counts as reproduced only when every run fails the same way. Nine out of ten is not enough.
0 AINo language model takes part in recording, replay or the verdict.
SealedReplay can't reach your real database or the internet. Any answer taken from the recording is listed.
0 linesof your app's source code changed to start recording.
Beyond the replay

What else one recording gives you.

The outputs shown on this page are examples. Crumbtrail reproduces failures in open-source apps from GitHub as well as our own test apps.

Wrong answers

Keep the request that answered wrong

Flag a request that returned the wrong answer without crashing. Crumbtrail keeps it and replays it, so you can compare its answer before and after a change.

GET /api/quote · 200 · shipping.total = 0 → keep
Where it started

Follow it back to the likely cause

The request that failed often isn't where the bug started. Crumbtrail lists the earlier requests that wrote the rows it read, so you know where to start looking.

POST /cart wrote cart 812 → POST /checkout read it → fails
Smallest repro

The smallest data that still fails

Crumbtrail cuts the recording down to the few rows that still trigger the bug, so a person can read it. Fix checks always use the full recording.

212 rows in 9 tables → 14 rows in 3 tables
Recheck

Recheck old bugs on a new build

Before a release, replay every saved failure against the new code and see which ones still happen.

crumbtrail compare <rec> --base main --head release
What it covers today

A short list, done properly.

This is what works today. Ask us about your setup during early access. If your app does something outside this list, replay flags it and makes no claim it can't back.

RequestsWeb requests that fail with an error
Supported
DatabaseRows each request read and wrote
Supported
CacheKeys each request read and wrote
Supported
Outside callsBlocked during replay, reported if unrecorded
Supported
More stacksMore languages and databases
In progress
Background jobsQueues and workers
Planned

Questions teams ask first

Do I need a copy of the production database?

No. Crumbtrail keeps only the rows each failing request touched, and rebuilds them in a throwaway database on your machine.

What does "same failure" mean?

The same status, error type, database error code and line in your code as production, on all 10 runs. The error message is saved but not compared.

Does "fixed" mean it's safe to ship?

It means the recorded failure no longer happens on any of 10 runs, against the recorded data. It doesn't promise the patch has no other bugs, or that the result is the right one for your business.

Do I have to change my code?

No. The recorder loads from your start command. The one setup step is a database setting that lets it see full rows when they change.

Does an AI decide whether the fix worked?

No. An agent can write the patch. The verdict comes from replay runs and fixed rules.

Can a replay touch production?

No. Each run gets its own throwaway database on the same machine, and all other network access is blocked. A call it didn't record fails the run, unless the app made the same call earlier in the recording. Those answers are listed.

What about passwords and API keys?

Environment values named like secrets, tokens, keys or passwords are dropped before anything is saved. Credentials in recorded outside calls are swapped for fakes.

How much does recording slow my app?

On our test app it adds about 0.45 ms per request with one user, and roughly doubles the app's CPU per request with eight at once. Measure it on your own traffic during early access.

Bring us one bug you couldn't reproduce.

Early access is open. Leave your work email to join the list.