Dev Bench watches your app for exceptions, failed and slow requests, and the “success” that wasn't: the handled error behind a page that told the user it worked. It triages each problem with your server's own log lines, files it in your GitHub with who was affected, and reopens it when it comes back.
Someone's always watching.
bundle add devbench
bin/rails generate devbench
# then set one value in your app's environment:
DEVBENCH_DSN=https://<public>:<secret>@adt-ingest.onrender.comThe generator adds the browser sensor to your layout and your CSP. No sidecar, no browser key, no initializer. Also for Go and any web page.
Uncaught exceptions, errors your code reports, failed jobs (ActiveJob, Sidekiq), panics, console errors.
Any fetch or XHR that got a 4xx or 5xx, or no answer at all, seen from the user's browser.
Slow requests, slow page loads and slow interactions, counted per route rather than per page view.
Your server caught an error and answered 200 anyway. One line marks it, and the browser knows the user was told something worked when it didn't.
The Rails gem, the Go SDK and the browser sensor fingerprint and count problems in-process. Traffic grows with distinct problems, not page views. Messages, stacks and log lines are redacted before they leave your app.
Each new problem is triaged with the stack, what the user was doing and the server log lines of that exact request, so the write-up says why, not just where.
Filed in a repo you choose, with how many users and accounts were affected. Close it when it's fixed; if it comes back, the issue reopens itself.
Support asks “what happened to jane@example.com?” Look her up by email or account and see every problem she hit, with links to the issues.
Run both side by side for a few weeks and compare what each caught.
Sales-led: we talk first, then start a pilot. No card form.
$10,000 / month
$20,000 / month
V2's additions are being built now. We'll tell you plainly what is live when we talk.
Talk to us about V2