Turn bug reports into fixes ready to review.
Praxen Inc. investigates each bug report using your production context. It proves the cause before it writes the fix.
Get started for freeReport
Report the bug right from Slack
Praxen Inc. already has your infrastructure, telemetry, recent changes and code, so there's nothing to explain. It turns the report into an issue and starts investigating.
Try it on a bugcheckout feels slow. is that us or payments-api?
Us. checkout-edge Wall Time P99 is 18× its own baseline
and the requests are queuing for a Hyperdrive connection, not on a downstream call.
payments-api is answering in 180ms, flat for a week.
Deploy 9f3c2a1 at 2:02 AM
shrank the hd-prod pool
from 50 connections to 5.
how long has it been queueing like that?
Nine minutes, since the deploy landed. It never went above 2 before that. I submitted a PR fix and tagged @justin to deploy 2 minutes ago.
Open in Praxen Inc. Configure
Cause
It finds the cause and proves it
Each step cites the query, log line or deploy behind it, or says what is still unknown. No proven cause, no fix.
Start debugging- 02:02:31 Fix run started
One agent, from the signal to the pull request.
- 02:16:41 Causal chain
- Signal (metric)
-
workers.invocation.p99_latency · checkout-edge
- Surfacing site
-
checkout-edge at Praxen Inc./checkout-edge:src/hyperdrive/pool.ts#withConnection
- Mechanism
-
withConnection waits for a free slot before it runs the query, so the P99 carries pool queue time, not database time
- Producer
-
hd-prod, at Praxen Inc./checkout-edge:wrangler.jsonc#hyperdrive
- Producer evidence
- queue-depth histogram grouped by colo: p99 wait 1.31s at 5 connections in flight, 0.04s below
- sandboxGrep: max_connections is 5 on the hd-prod binding; the worker opens up to 50
- change record 9f3c2a1: max_connections 50 → 5
- Trigger
-
deploy 9f3c2a1 took max_connections from 50 to 5, 18 minutes before the first breach
- What happens to the failed unit today
-
unknown: whether the storefront retries the confirm: Praxen Inc./storefront-web is not a connected repository
- Cadence check
-
one queued request per checkout past the fifth in flight matches the 118 breaches and the gaps between evening peaks
- Blast radius
-
2 other resource(s), 0 other tenant(s); data at risk: none named
Every link rests on named evidence, or is written as unknown: <what would establish it>. Counts, not adjectives. If the cause isn't proven, no fix ships.
- 02:24:09 Pull request #412
Restore Hyperdrive pool size in checkout-edge
Fix
It writes the fix and explains it
Praxen Inc. writes the change on a branch, validates it and explains its reasoning. Prefer your own agent? Connect Devin, Cursor, Factory or Conductor.
Start fixingCap retries on the checkout webhook worker #491
praxenmain from praxen/autofix/chat/k3x9f2-4e7d21a Retries on the checkout webhook worker were unbounded: a failing delivery re-queued itself forever and amplified load on payments-api. This caps delivery at 5 attempts with exponential backoff and dead-letters the payload after the last one.
What changed
worker/deliver.ts gains MAX_DELIVERY_ATTEMPTS = 5 and backoff between attempts; exhausted payloads land in checkout-webhooks-dlq instead of re-queueing.
Validation
npm test: 214 passed. A forced failing delivery stopped after 5 attempts and appeared in the dead-letter queue.
Praxen Inc. takes tickets from wherever you work.
- bug report thread, CLI or editor
Takes bug reports from anywhere
Describe the bug in a thread, over the CLI, or from your editor through MCP.
- executor Praxen Inc.'s by default
Works with your coding agent
Connect Devin, Cursor, Factory or Conductor with your own key. Praxen Inc.'s own executor is the default.
- ticket 1 cause confirmed
- ticket 2 starts from it
Learns from past tickets
What it confirms on one ticket is remembered and used on the next.
- new branch the fix
- investigation linked
Fixes it in the right repo
Connected through the GitHub app, the fix lands on a branch in the repo behind the affected service.
- cause proven
- unknown: no fix
Only proven causes
Each step cites its evidence or says what is still unknown. No proven cause, no fix.
- resolved
- diagnosed
- inconclusive
Tells you the result
An investigation ends resolved, diagnosed or inconclusive. Anything that needs a person becomes one escalation.
It plugs into what you already run.
Loved by developers
Related guides
- Guide How to use Claude Code to debug production issues Debug production issues with Claude Code: get logs and traces into the session, test hypotheses against evidence, stay read-only and ship a verified fix.
- Guide How to debug Cloudflare Workers errors: logs, traces and error codes Debug Cloudflare Workers errors step by step: read 1101 and 1102 codes, enable Workers Logs and source maps, use wrangler tail, DevTools and local traces.
- Guide How to debug Vercel function timeouts Debug Vercel FUNCTION_INVOCATION_TIMEOUT 504s: find the slow call with vercel logs and httpstat, fix hangs, set maxDuration and verify on a preview.
- Blog Nobody reads pull request descriptions, so we made videos Almost none of the pull requests Praxen Inc. opens were asked for by an engineer, and a longer description does not make them easier to review. We are experimenting with a narrated video for every fix. Why, what it looks like, and what happened to merge rates.
- Blog We swapped our LLMs for Jev. It's 39% cheaper. Our agent makes thousands of small decisions a day. We moved them from LLMs to Jev, a model that doesn't write text, and cut the cost by 39%.
- Blog Sub-agents are just wrong Praxen Inc.'s autofix used to be a workflow of multiple agents, each responsible for a single task, with an orchestrator managing state between them. We moved to a single agent which does the entire job, from evidence gathering, hypothesis testing to pull request.
Common questions.
How do I hand Praxen Inc. a ticket?
Mention @Praxen Inc. in Slack, start a thread in the console, or use the CLI or your editor over MCP. Praxen Inc. already has the graph, the telemetry, the recent changes and the code.
What if it can't find the cause?
It says so. An investigation ends resolved, diagnosed or inconclusive, and anything that needs a human decision becomes a single escalation.
Does it learn from past tickets?
Yes. What it confirms on one ticket is remembered and used on the next, and daily notes keep a record of what happened.
Who writes the fix?
Praxen Inc.'s own executor by default, or connect your own coding agent and every autofix routes through it. Either way, you review it before it merges. Supported agents are at getpraxen.app/integrations.
Which repositories does it work with?
Any repository you connect through source control. The fix lands on a branch in the repo behind the affected service, with the investigation linked from the change. Supported providers are at getpraxen.app/integrations.
Can I ask for a fix from Slack?
Yes. Mention @Praxen Inc. in any channel or DM. Updates come back to the same thread: failed CI, the merge, the close. Reply there to steer it.
Does it test several theories at once?
Only when you ask. By default one agent does the work; ask for a swarm and several agents test the open questions in parallel.
What if there is nothing to fix?
Praxen Inc. says so. It won't invent a diff to look busy.
What happens to a fix nobody reviews?
One reminder after a week, then Praxen Inc. closes it and says why. The branch stays, so reopening brings the change back unchanged.