I built an error tracker that opens the pull request for you (self-hosted, PHP/JS/Flutter)

Every error tracker I have used stops at the same place: here is the stack trace, here is how many times it happened, good luck. The next 40 minutes — open the file, read the code around the line, figure out the change — are always mine. I wanted that part to happen before I open the ticket. So I built Bugban. Grouping. A fingerprint (class, file, line, normalised message) keeps repeats together: first seen, last seen, count, status. Context. The request (method, URL, route template, Controller@action), the signed-in user, the session, breadcrumbs, device, and — on browser projects — a DOM snapshot with every input masked. AI analysis, in your language. Root cause, explanation and a concrete fix, written in the language of your panel (English, Azerbaijani, Russian, Turkish). A pull request. A GitHub App reads only the files the stack trace points at, at their current state in your repo, and pushes a whole-file change to a bugban/fix-<id> branch. Merging is yours; nothing touches main by itself. Some guard-rails I found necessary in practice: Only new or reopened errors trigger a fix — never every occurrence. One open PR per error, a daily limit per project. The model may answer "I'm not sure" and return no files. That is a normal, successful outcome. We ask for the whole file, not a diff. Models get line numbers wrong in unified diffs; a whole file either parses or it doesn't. merged is not deployed. The old code is still running after a merge, so Bugban does not auto-resolve the error; you mark it resolved after deploy, and only then can a second attempt happen. Queries over your threshold arrive with their EXPLAIN: full scan vs index, rows examined, key used. Two lessons from real customers ended up as product rules: type=index in MySQL is a full index scan, not "index used". The panel reads the plan detail instead of trusting the flag. A leading-wildcard LIKE '%x%' cannot be helped by any B-tree index. The panel says so up front instead of letting an AI recommend one. There is also a re-run button. It measures a slow query again — executed by your SDK on your database, single read-only statement, forced LIMIT, always rolled back, and only the duration and row count come back. Row contents never leave your server. Regression tracking measures frequency (slow occurrences per hour), not average duration — because the SDK only reports queries above the threshold, so after a fix the average goes up while the problem is actually gone. React Native, Expo and Flutter get a real PNG screenshot, with sensitive widgets painted over before the shutter. There is an offline queue written to disk before sending, so an error in a lift or a fatal crash is replayed on next launch. Performance on mobile uses app start, screen load and jank — not Web Vitals, because LCP means nothing on a phone, and an AI prompt written for browsers would confidently discuss render-blocking CSS that doesn't exist. In-app, email, Slack and Telegram on every new error. A separate high-load alert watches for a spike within a window and can place an actual Telegram phone call to the person on duty. PHP 7.0 → 8.4: bugban/laravel, bugban/symfony, bugban/codeigniter, bugban/yii2, plain bugban/php-sdk (Composer or a manual autoload) JavaScript: @bugban/node, @bugban/express, @bugban/nestjs, @bugban/next, @bugban/react, @bugban/vue, @bugban/react-native Dart: bugban_flutter on pub.dev composer require bugban/laravel # .env BUGBAN_API_KEY=... BUGBAN_HOST=https://your-bugban Per-stack guides: Laravel, Node, Flutter, React Native and the rest at bugban.online. By projects, not by events or seats. Every package includes everything, AI fixes included. 7-day trial, no card. I would genuinely like to hear what you would want from an error tracker that also writes the fix — and where you would not trust it. Comments welcome.