Rollbar Laravel Package

Product Decisions This Supports

• Vendor selection for error monitoring — the decision that actually matters. This package is an adapter, not a platform. It becomes relevant only after Rollbar is chosen as the error-monitoring vendor of record versus Sentry, Bugsnag, Datadog, or Flare. It is a downstream implementation detail and must never be an input to the vendor call itself.
• Build vs. buy, two layers deep. Layer one: buy managed error monitoring or build in-house alerting. Layer two, inside "buy": thin community wrapper (this), Rollbar's official rollbar/rollbar-laravel SDK, or a hand-rolled PSR-3 logging channel. The wrapper is the cheapest to wire and the most expensive to own — that trade-off is a PM decision and should be made explicitly, not by whichever package a developer finds first.
• Roadmap enablement, not a roadmap feature. Production exception capture, user/request context on errors, deploy tagging, and post-incident triage move from "a sprint" to "days." This is the plumbing behind on-call readiness and release-health gating — a prerequisite for any reliability commitment, resourced as such, and never sold to customers as a feature.
• Fleet standardization and tech-debt triage. If the fleet still contains legacy Laravel 5.x / PHP 7 apps on Rollbar, this package supports a cheap bridge decision. If any target service is Laravel 8+/PHP 8, it supports the opposite answer: skip it and fund a migration ticket. Same package, two opposite portfolio decisions — the fleet inventory decides which.
• Prioritization signal for the dependency portfolio. Zero stars, zero dependents, archived upstream, single maintainer. That is the definition of commodity glue with no ecosystem gravity. It should never appear on an architecture diagram as a dependency, and "it's already integrated" must not be allowed to anchor us to an unsupported framework version.
• Use cases it genuinely fits: inherited legacy apps already paying for Rollbar; multi-language orgs consolidating on one monitoring tool (JS/Python/PHP) where vendor uniformity beats Laravel ergonomics; internal or low-criticality apps where a half-day pilot is cheaper than a design debate.

When to Consider This Package

Consider it when:

• Rollbar is already approved and procured, and the target app's Laravel/PHP versions fall inside this wrapper's ceiling (roughly Laravel 5.x / PHP 7.x, with v1.5.1 as the Laravel 5.4 bump).
• The app is a legacy monolith where the alternative is a multi-day migration to the official SDK that delivers no visible user value this quarter.
• You need a bounded, time-boxed pilot (half a day to a day) to prove the error-reporting pipe before committing engineering budget.
• The team can afford the guardrails: a pinned version, an ErrorReporter interface in front of the facade, a smoke-test route, scrubbing sign-off, and an owned migration ticket filed on day one.
• Org-level vendor uniformity is worth more than Laravel-native ergonomics — e.g., consolidating JS, Python, and PHP services on a single Rollbar account.

Look elsewhere when:

• The app is Laravel 8+/PHP 8. The illuminate/support constraints will not resolve; use rollbar/rollbar-laravel. This is a hard stop, not a trade-off.
• Another tool already owns App\Exceptions\Handler (Sentry, Ignition, Telescope, or a custom reporter). Two competing chains mean duplicate quota burn and incoherent triage. Pick exactly one owner.
• You need advanced capabilities: per-tenant token routing, custom payload shaping, batching, or sophisticated sampling. Those live in rollbar-php; you'd be fighting the wrapper to reach them.
• Reliability is a customer-facing commitment. Synchronous transmission on the error path plus a zero-maintenance upstream is an incident waiting to happen unless you invest in timeouts, sampling, and payload caps up front.
• No one on the team will own the migration. Unmaintained wrappers become upgrade blockers; if nobody is accountable, don't adopt it.

How to Pitch It (Stakeholders)

For executives: This is a small, cheap adapter that connects a legacy Laravel application to Rollbar, the error-monitoring vendor we've already chosen. It is not a product feature and it is not a platform decision — it is the plumbing that turns "users got a 500 this morning" into a triaged ticket with a stack trace, affected user, and release version. Expect days of effort, not a sprint, and expect the business value to show up as reduced mean time to resolution and fewer silent failures.

Frame the real decision honestly: the wrapper is free to wire and expensive to own. Zero stars, zero dependents, an archived upstream, and a version ceiling at Laravel 5.x mean every future framework upgrade is blocked until we replace it. So we approve it only for the legacy estate, on three conditions: the version is pinned exactly, error reporting is hidden behind an internal interface so the eventual swap is one class, and a migration ticket is opened the day it ships. That framing converts an "it's just a Composer package" conversation into a disciplined, time-boxed decision rather than an accidental architectural commitment.

For engineering: The value is that uncaught exceptions, Log::error() calls, and custom events reach Rollbar with request/user context and stack traces without manual instrumentation. The risks are equally concrete. The package fails silently — a bad token yields a healthy-looking dashboard and zero telemetry — so the smoke test is mandatory, not ceremonial. The transport is synchronous on the error path, so under an error storm every request blocks on an HTTPS POST; we cap the timeout at ~2s, sample, and load-test a synthetic error burst in staging before canary. Payloads carry PII, so scrub_fields needs a named owner and a sign-off. And we isolate the facade behind an ErrorReporter interface so product code never imports it directly.

For the wider org: Error monitoring here is vendor-standardized, not Laravel-idiomatic — useful if we're consolidating on Rollbar across languages, a liability if we later standardize on Sentry or Datadog. Treat this as a bridge with a documented end date, not a foundation.