Dev Bench watches the errors, and the errors that don't show up as errors. It watches what your users do and notices when they don't get what they wanted. It picks up their requests, files the issue, drafts the fix with tests and documentation, and opens a pull request for your team.
Nothing ships without your team's approval.
For software companies, consultancies and dev shops running apps after launch.
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.
Keeping the lights on starts as a fifth of the team's time and ends up as most of it. Every one of these problems matters, and every one loses to whatever is more urgent today. What gets demoted gets neglected, and what gets neglected gets forgotten.
Tickets pile up, duplicates multiply, fixed bugs stay open, and keeping the lights on eats the sprint until deadlines slip.
What the bench does: Problems are triaged and filed with who they hit, and repeats are grouped. Fixes arrive as pull requests.
At launch someone read every log line and sat with every user. By customer ten, nobody can afford to, and the alerts go to a folder.
What the bench does: It watches every request, including the handled error behind a 200 that told the user it worked.
They get written when a new hire is lost or diligence is coming, and the oldest parts of the app never get them.
What the bench does: Documentation and release notes are drafted from what actually shipped, as pull requests.
Most complaints never become tickets. When a fix does ship, nobody tells the person who asked, so they stop trying.
What the bench does: Users report problems and ask for changes inside your app or in Slack, and hear back in the same thread.
Each hire adds a little capacity and a lot of overhead. The appetite for development is never met, and budgets stop growing.
What the bench does: AI developers pick up the work and open pull requests. Your developers review instead of starting from zero.
Users invent shortcuts and 100-click workarounds, then a release removes a step in a workflow you never knew existed.
What the bench does: Custom signals watch the events that matter to your business and tell you when something changes.
Teams already have more tools and reports than anyone reads. Buying one more is easier than changing the work.
What the bench does: It is headless: issues and pull requests in your GitHub, conversations in Slack. Nothing new to ignore.
Under pressure, tests become theater: the happy path, getters and setters, a coverage number to hit.
What the bench does: Every pull request it opens comes with tests for the change and runs your whole suite.
What does keeping the lights on cost your team? Run your numbers →
Sensors in your app count errors, failed and slow requests and silent failures, redacted before they leave it. Users and staff report problems and ask for changes in a chat inside your app, or in Slack.
Each problem is triaged with the stack, what the user was doing and the server log lines of that exact request, then filed in your GitHub with who was affected. Repeats are grouped into the same issue, and if it comes back, the issue reopens.
An AI developer writes the fix or the feature with its tests and documentation, runs your test suite in your own GitHub Actions, and opens a pull request.
Your developers, or your own AI agents, review and merge. The person who asked hears back in the same chat or Slack thread when it ships.
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.
Issues and pull requests land in your GitHub. Conversations happen in Slack and in your app. There's nothing new to log into, and nothing to ignore. Here is what it watches:
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.
Already on Sentry? Run both side by side for a few weeks and compare what each caught.
When something was busted, it went on one side of the bench. A technician fixed it and drove it across town, Thanksgiving Day included. I got into software so I wouldn't have to be the one driving.
Twenty-five years later, most software teams are still on call. They just do it in Slack, GitHub and Sentry instead of a customer's parking lot. In software, the bench is also where developers wait, ready to be deployed. Dev Bench is that bench: always there, always picking up the next thing.
We're working with a small group of early customers. Request access and we'll talk first. Paid through Stripe by card or US bank account (ACH); one is required to start.
$10,000 / month, billed annually
or $12,000 / month, billed monthly
$20,000 / month, billed annually
or $23,000 / month, billed monthly
Add-on for either edition: custom signals, which watch the events that matter to your business and tell you when something changes.
We're taking the next round of early-access customers. Tell us about your app.
Request early access →