Rollbar Laravel Package

Technical Evaluation

Architecture fit. This is an adapter, not a platform — a thin wrapper that wires rollbar-php into Laravel's exception handler and Monolog stack. It belongs nowhere on an architecture diagram. The correct framing for a TPM is: this package is only relevant after Rollbar is already the vendor of record. It must never be an input to the vendor decision itself. Where it fits is narrow and real — inherited Laravel 5.x / PHP 7.x monoliths that are already paying for Rollbar, and multi-language orgs consolidating on one monitoring vendor where uniformity beats Laravel ergonomics.

Integration feasibility. Genuinely cheap where compatible: a competent Laravel developer can wire it in half a day — composer require jenssegers/rollbar:1.5.1 (pinned, not ^1.5), provider registration (auto-discovered on 5.5+, manual on 5.4), vendor:publish, two env vars, one smoke-test route. The work is not the install; the work is the guardrails around it.

Technical risk. Ranked by what would actually cost a sprint or an incident:

• Silent failure is the default. A wrong token, blocked egress, or environment-name mismatch produces zero telemetry and zero warnings. A green-looking dashboard is an unverified claim, not evidence.
• Synchronous transport on the error path. Under an error storm every failing request blocks on an HTTPS POST to Rollbar before returning a 500. This is the classic path from partial degradation to full outage. Timeout, sampling, and payload caps are mandatory, plus a staging burst test to measure the latency delta before canary.
• Composer conflict is likely, not exceptional. Constraints on illuminate/support and the transitive rollbar-php version can shift payload semantics with no code change.
• PII exposure. Payloads carry request bodies, headers, cookies, and session IDs. scrub_fields must be verified to actually reach the SDK; a missing field is a compliance incident.
• Competing handler. Sentry, Ignition, Telescope, or a custom reporter in App\Exceptions\Handler means duplicate quota burn and incoherent triage. Telescope in particular makes reporting look like it works when only Telescope is seeing it.
• Abandonment. v1.5.1 was the last bump; upstream is archived. Every future Laravel upgrade is blocked until this is replaced.

Key questions a TPM should put to the team before approving:

1. What Laravel/PHP versions are actually in the target fleet, and is any service on Laravel 8+/PHP 8? (If yes, this package cannot resolve and the answer is the official SDK.)
2. Is Rollbar already procured and approved — or is this package quietly deciding the vendor question by convenience?
3. Who owns App\Exceptions\Handler today, and are we prepared to name exactly one reporting owner?
4. Who signs off on the scrub field list, and by when?
5. What is the timeout / sampling / payload-cap configuration, and who has run the synthetic burst test?
6. How many engineer-days are budgeted for the eventual migration to rollbar/rollbar-laravel?

Integration Approach

Stack fit. Hard ceiling of roughly Laravel 5.x / PHP 7.x. The version check is the first gate and the answer is binary: inside the ceiling, half-day wire-up; outside it, stop and use rollbar/rollbar-laravel, because the illuminate/support constraints will not resolve anyway. Do not let "it's already integrated somewhere" anchor the fleet to an unsupported framework version.

Migration path. The one architectural move that makes abandonment survivable is wrapping the facade behind an ErrorReporter interface on day one. Product code should never see \Rollbar:: or the Rollbar alias — both the alias collision risk and the eventual swap disappear if the facade stays out of business logic. When the migration comes, it is one new class and one binding change. Keep config/rollbar.php keys (access_token, environment, level, scrub_fields, person_fn, max_items, batch_size) aligned with the official SDK's names so the swap is a config diff, not a redesign — and so the scrubbing review doesn't reopen.

Compatibility. Commit composer.lock. Resolve composer conflicts before committing a sprint, not mid-sprint. Treat any composer update that drags in a newer rollbar-php as a payload-affecting change requiring review.

Sequencing (the order matters):

1. Fleet inventory and version gate — decide "legacy bridge" vs. "official SDK" per service.
2. Pin 1.5.1; resolve composer constraints.
3. Register provider / facade alias (check the facade namespace against the pinned src/Facades/).
4. Publish config; set per-environment tokens and environment names in .env — never hardcode, never share a token across environments.
5. Smoke-test route in staging — throw, confirm arrival in the correct Rollbar environment. This is the highest-value ten minutes of the whole project.
6. Introduce the ErrorReporter interface and binding; strip scattered facade calls.
7. Scrub-field review and sign-off.
8. Configure timeout, sampling, payload caps; run the synthetic burst test and measure.
9. Canary to production.
10. File the migration ticket the day it ships — not after the first incident.

Reporting patterns worth standardizing, because they determine whether triage is usable: let the global handler do the work and resist sprinkling reportException through controllers; report at boundaries where errors would otherwise vanish (queued jobs that swallow after retries, webhook handlers that must return 200, cron console commands); use structured context arrays so fields survive into Rollbar; attach person identity via person_fn in config rather than middleware; and tag deploys with the release SHA so an error spike is correlatable to a deploy.

Operational Impact

Maintenance. Effectively zero upstream maintenance — single maintainer, archived, zero dependents, zero ecosystem gravity. The realistic posture is that the org owns this code. That is fine for a bounded legacy bridge and unacceptable as a long-lived default.

Support. Community only, no vendor escalation path. Assign an internal owner at approval time; "no named owner" is how silent-failure drift goes undetected for a quarter.

Scaling and cost control. The config surface is small (person_fn, the config array, the registered Monolog handler) and that is the point — but it also means anything sophisticated (multi-tenant token routing, custom payload shaping, advanced sampling) means fighting the wrapper toward rollbar-php. Set level at error or warning; dropping to debug on a chatty app exhausts quota and destroys the triage queue. Keep timeout short (2s), cap max_items, and hedge with sample_rate — verifying which key the pinned rollbar-php actually honors.

Failure modes to plan for:

• Silent non-delivery (bad token / blocked egress / env mismatch) — mitigate with a staging smoke test or an artisan command that asserts on the API response.
• Latency cascade during an error storm — mitigate with timeout, sampling, and a pre-canary burst test.
• Duplicate or incoherent reporting when a second handler owns the exception path.
• Payload drift from a transitive rollbar-php upgrade with no code change.
• PII leakage from an unverified scrub list.
• Disable in local/test via empty token (or environment-guarded provider registration) so the suite makes no outbound calls.

Ramp-up. Half a day for a Laravel developer to install and prove the pipe. Budget two to three days of engineering plus a security/compliance review for the parts that actually matter: interface wrapper, scrub verification, burst test, handler ownership documentation. The install is cheap; the operational guardrails are the real cost, and skipping them is how a half-day integration becomes an incident review.

Portfolio signal. Zero stars, zero dependents, archived upstream, single maintainer, score 0.3 — this is commodity glue. Fund it as a deliberate, time-boxed legacy bridge with a migration ticket attached, or skip it entirely for Laravel 8+/PHP 8 targets. Never let it become the thing that decides which framework version the fleet is allowed to run.