redexperts/errbit-bundle
A Symfony bundle that connects PHP applications to Errbit, the Airbrake-compatible error tracker. It captures exceptions and sends structured reports to your Errbit server, making production error monitoring easier to set up and maintain.
Read this first: redexperts/errbit-bundle is a Symfony 2 bundle, not a Laravel package. It ships no service provider, no facade, no config file under config/. It was last released in March 2015, targets Symfony 2.x HttpKernel conventions, and has zero dependents. You will not composer require it into a modern Laravel app and get working error reporting — Composer will fight you on Symfony component constraints, and the PHP runtime expectations are pre-7.2.
What it does do is conceptually simple and worth understanding before you touch it: it registers an event listener on kernel.exception that formats the exception into an Errbit/Airbrake "notice" and POSTs it to an Errbit instance's /notifier_api/v2/notices endpoint, tagged with a project API key and environment. That's the whole value proposition.
Minimal practical path for a Laravel developer:
/notifier_api/v2/notices endpoint. This is the thing you actually care about.DependencyInjection/ extension (to see which config keys exist — typically host, api_key, environment, resource/project_root, secure) and the exception listener (to see what payload fields it sends — notifier name/version, error class/message/backtrace, request URL, params, session). You're mining the payload shape, not adopting the code.App\Exceptions\Handler::report(). That's the single seam where Laravel gives you every uncaught exception. One Http::post() to the Errbit endpoint with the mapped payload beats a whole bundle.The realistic verdict: treat this repo as reference material for the Errbit wire format, not a dependency.
Since the package won't integrate directly, the "patterns" are the ones the bundle implies, re-implemented natively in Laravel.
1. Handler-centric reporting.
Override report() in App\Exceptions\Handler. Guard on app()->environment(...), skip Reportable duplicates, and hand off to a dedicated ErrbitReporter service resolved from the container. Keep the handler thin — the bundle's listener-equivalent logic belongs in that service.
2. Payload mapping. Build the notice to match the Errbit/Airbrake v2 schema the bundle would have produced:
notifier: name + version (Errbit ignores it mostly, but include it)errors[0]: type (exception class), message, backtrace (array of {file, line, function} — convert getTrace() accordingly)context: url, component, action, environmentrequest: params, session, cgi-data (headers)Errbit's UI groups and filters on these fields, so getting component and action right materially improves triage.
3. Context enrichment via middleware.
The bundle can't know your authenticated user or request IDs. In Laravel, use a middleware or the Context facade to stash user_id, request_id, tenant_id, then have the reporter fold those into context. This is where a native implementation beats the bundle — you're not fighting Symfony's RequestStack.
4. Async dispatch.
The bundle POSTs synchronously in the kernel exception path — a slow Errbit instance stalls the response. In Laravel, dispatch a ReportToErrbit job (or use Http::withOptions(['timeout' => 2]) plus a queued job) so error reporting never takes down your user-facing latency.
5. Filtering and suppression.
Wrap the reporter in filters: ignore ValidationException, AuthenticationException, ModelNotFoundException (404s), and anything in a dontReport list. Rate-limit per exception signature (hash of class + first trace frame) with RateLimiter to avoid flooding Errbit during an outage loop.
6. Multi-environment routing.
The bundle keys off kernel.environment. In Laravel, key off APP_ENV and point staging/production at separate Errbit projects (separate API keys). Don't let local dev spam the shared project — either disable or tag environment: local and filter in the Errbit UI.
7. If you truly want to reuse the bundle, create a small Laravel service provider that binds the bundle's notifier class manually — but first confirm the class has no Symfony\Component\HttpKernel type-hints. In practice, extracting the 100–200 lines of notifier logic into your own class is faster and safer than a compat layer.
composer.json you expect to update.kernel.exception events, Symfony\Component\HttpFoundation\Request, and DI tags. None of that exists in Laravel's pipeline. Forcing it in through a bridge usually costs more than writing ~150 lines yourself..env (ERRBIT_API_KEY), never in config/ committed to git, and rotate if a notice payload leaks them via request.params — sanitize params before serializing.params, session, and cgi-data. Scrub password, password_confirmation, token, authorization, cookie, and any *_secret keys recursively. The bundle cannot know your app's sensitive field names — you must.vendor/, node_modules/) if you can, to keep the first-party frames visible where it matters./notifier_api/v2/notices — a trailing-slash mismatch or missing path yields silent 404s. Log the HTTP status on failure and fail open (never let reporting break the original exception flow).verify => false; if you must disable it, scope it to that one client instance, not globally.throw new \RuntimeException('errbit smoke test') in a tinker session against a staging key. Inspect the raw JSON with Http::dd() before trusting error grouping — Errbit groups by exception class + a fingerprint of the top frame, so a shifting frame (e.g., closure line numbers) causes duplicate issues.host, api_key, environment, resource, secure) map cleanly to a Laravel config/errbit.php. Its notifier version string is only cosmetic — you can set your own. Its listener logic is the only substantive piece; port it, don't wrap it.How can I help you explore Laravel packages today?