ftrrtf/rollbar-bundle
Symfony bundle for Rollbar error monitoring that configures the Rollbar client, wires services, and automatically reports exceptions and errors from PHP applications. Track production issues with minimal setup through standard Symfony configuration and an exception listener.
Start with a reality check before you write any code. This is a Symfony 2 bundle, not a Laravel package: it ships a DependencyInjection/ extension, a Resources/config/services.yml, and a *Bundle entry class, and it depends on symfony/symfony ~2.x plus a 0.x-era rollbar/rollbar-php. Running composer require ftrrtf/rollbar-bundle inside a Laravel app will fail dependency resolution rather than install something useful. It is also archived (last release 2018-05-18) with zero dependents, so there is no maintenance path.
So "getting started" for a Laravel developer means mining the bundle rather than installing it. Read these three files in the repo in this order:
DependencyInjection/Configuration.php — the canonical list of knobs the authors considered worth exposing (access_token, environment, root, branch, handler, level, person_fn, batching). Treat it as the spec for your own config file.Resources/config/services.yml — shows the two wiring styles the bundle supports: a singleton notifier service and a Monolog handler.FtrrtfRollbarBundle.php — the compiler passes, if any, tell you what it auto-registers.Then install the SDK the bundle was wrapping, because that part still works and is still maintained:
composer require rollbar/rollbar-php
First use case: bind a single Rollbar\RollbarLogger as a singleton in a service provider driven by config/services.php, and report unhandled exceptions from the exception handler. That reproduces 90% of the bundle's value in ~40 lines you control.
Singleton logger, container-configured (the bundle's core pattern). The bundle builds one client from config at container compile time. In Laravel:
// AppServiceProvider::register()
$this->app->singleton(RollbarLogger::class, fn ($app) => new RollbarLogger([
'access_token' => config('services.rollbar.token'),
'environment' => config('services.rollbar.environment'),
'root' => base_path(),
'branch' => config('services.rollbar.branch', 'main'),
'code_version' => config('services.rollbar.code_version'),
'max_items' => 10,
'batch_size' => 50,
'scubber' => config('services.rollbar.scrub_fields'),
]));
Two reporting paths, and only two. The bundle's structure implies an exception listener and a Monolog handler. Mirror that but keep them disjoint:
// bootstrap/app.php (Laravel 11) or App\Exceptions\Handler::report (10 and below)
$exceptions->report(function (Throwable $e) {
app(RollbarLogger::class)->report($e);
return false; // fall through to Laravel's default logging
});
// config/logging.php
'rollbar' => [
'driver' => 'monolog',
'handler' => Rollbar\Monolog\Handler\RollbarHandler::class,
'handler_with' => ['rollbarLogger' => app(RollbarLogger::class)],
'level' => 'error',
'bubble' => false,
],
Point a single Log::channel('rollbar') at it and use it explicitly (Log::channel('rollbar')->error(...)) rather than putting it on the default stack — otherwise every Log::error becomes a Rollbar item and you lose the ability to tune volume per subsystem.
Person and request context via middleware. The bundle's person_fn config hook is a callback-resolved identity. In Laravel that's cleaner as middleware that sets and clears context around the request:
Rollbar::scope(function (RollbarLogger $l) use ($request) {
$l->configure(['person' => ['id' => Auth::id(), 'username' => Auth::user()?->email]]);
// or ->addCustom / ->setCustom for route, request id, tenant
});
Queue jobs. Don't rely on the global handler inside jobs; call report() explicitly in failed(Throwable $e) on the job base class, so the payload carries the job class and queue name. Closures and unserializable payloads must be stripped before reporting.
Deploy tracking and fingerprints. The branch/code_version keys in the original Configuration.php exist so Rollbar can correlate regressions to deploys — fire the deploy endpoint from your release script. For noisy items, use custom_data.rollbar.fingerprint to force grouping rather than muting.
Sampling / ignore lists. Both the bundle and the SDK expect an check_ignore (or before_send) callable. Use it to drop NotFoundHttpException, ValidationException, and AuthenticationException — Laravel throws these for normal control flow and they will drown your feed.
rollbar-php is 0.x; the API surface has changed (namespace reshuffles, RollbarLogger::report arguments, sender config keys). Verify every snippet against the current rollbar/rollbar-php README before porting.report() will create three copies of the same error. Pick one reporting path per error class and set bubble => false.person and custom data across requests. Always scope or reset context at the start of each request and each job, or you'll tag errors with the previous user's identity — a genuinely serious bug for multi-tenant apps.ftrrtf_rollbar root key and its own names; the SDK uses access_token, environment, scrub_fields. Don't assume the bundle's key naming carries over.scrub_fields / Scrubber config is your only defense against passwords, tokens, and auth headers landing in the payload. Laravel's dontFlash and $dontReport do not apply to a third-party reporter.phpunit.xml (ROLLBAR_TOKEN=null, or call Rollbar::setEnabled(false) in setUp) or your suite gets slow and flaky.post_client_item token.APP_ENV to a stable Rollbar environment string (production, staging) — don't send local or per-branch values, or the items fragment across environments and regressions become invisible.handler config key (swap the transport for a queue-based sender), the person_fn callback (identity abstraction), and the compiler pass pattern (only useful if you're actually writing a Laravel package).How can I help you explore Laravel packages today?