Last month a customer got stuck on checkout. No email. No complaint. They just left.
I found out 4 days later, from a single log line. Then I spent hours in the logs and the database and never found the cause. The bug was still out there, and all I could do was wait for it to hit someone else.
That’s when I stopped asking “how do I read logs faster?” and asked a different question: why is a person the one who has to tell me it’s broken?
The surprise: you don’t point it at the code
When I imagined an AI debugger, I pictured pasting in an error and getting a patch. That’s not how a stuck customer works. A stuck customer often throws no error at all. The button does nothing, the page hangs, the payment step never fires.
So Bugwalk starts somewhere else. It starts from the person.
It reads their visit in order: every click, every request, every error, on one timeline. Then it reads your code at the version that was live when they failed. Then it names the line.
What it found in the demo (and why I didn’t expect it)
Here’s a real example from the live demo, a small online shop called Fernhill.
The timeline shows a shopper logging in fine (200), then TypeError: Cannot read properties of null, then POST /api/checkout returning 500.
The investigation reads: a coupon that is not in the discount table is read as if it were, so checkout throws before the shopper sees a price.
Look at what kind of bug that is. It doesn’t hit everyone. It hits only people who arrive with a coupon code from an email. Click the code, load checkout, nothing. I could test checkout all day and never see it. A shopper who left would just look like a dropped cart.
That’s the kind of bug I spent hours failing to find.
How you can use it
The path is short. This is straight from the quick start:
- Create a project and name it after the app you want to watch.
- Install the SDK. Run the wizard from your app, or paste the snippet for your framework.
- Open your app once. A page view is enough to see the first event.
- Connect your GitHub repository. This lets a report point at the exact line.
- Open a failed session and press “Run investigation.” Review the pull request it opens.
The part I care about most: it can’t touch what matters
I wouldn’t let a stranger loose in my repo, so here’s what it can and can’t do:
- It can read the repositories you choose, run their tests, create one branch, and open a pull request.
- It cannot push to your default branch, comment, merge, or write to your database.
- Every fix is a pull request on its own branch. Nothing ships until you approve it.
What it actually saves
Finding a small bug by hand takes about four hours (a rough estimate, not a benchmark). Those hours cost three things:
- Time: scrolling logs, running queries, guessing what the user clicked
- Brain rot: ten tabs and one half-theory in your head
- Focus: the feature you were building is gone, and you rebuild it from nothing afterwards
What you get instead is one pull request to read. You stay on your feature, and the details were already gathered.
Try it without signing up
You don’t have to trust my write-up. The demo is a real shop with real failures, and it needs no account: bugwalk.app/demo
If you want to run it on your own app, there’s a 3-day trial.
It’s early, and I want to hear from you
How do you find out a user hit a bug today: Sentry, session replays, support tickets, or luck?
How long does a “can’t reproduce it” bug cost you?
Would you let a tool like this open PRs on your repo, and what would it need to show you before you trusted the fix?
Tell me in the comments.
Top comments (1)
tr.ee/dev-to