Sentriable Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for observability. This package is thin glue on top of sentry/sentry-laravel (itself glue on sentry/sentry-php). Adopting it is not a Sentry commitment — it's a decision to stop hand-rolling error-reporting wiring in each Laravel service. The real buy-vs-build decision is Sentry; this package only lowers the cost of the "buy" path.
• Launch readiness as a gate. Lets you define "ships with production error tracking from day one" as a standing requirement for new Laravel services, because the integration cost is minutes rather than a setup task someone has to own.
• Standardization across a portfolio of Laravel apps. One dependency and one config convention means exception handling, environment tags, and release tagging look the same everywhere — which is what makes cross-service triage actually work.
• Feature-level payoff: faster incident triage (stack traces tied to release + environment), fewer "cannot reproduce" support tickets, and better prioritization because you see real exception volume rather than reported exception volume.
• On v2.1.0 specifically: a patch-to-minor bump (2.0.1 → 2.1.0) with a changelog link as the only artifact — no documented breaking changes, deprecations, or feature descriptions. Treat as low-risk additive; no roadmap replanning warranted. Pin the version, let automated dependency updates take it, and read the compare diff before merging if you're conservative.

When to Consider This Package

Consider adopting when:

• Sentry is already the chosen (or already purchased) error-tracking backend, and you run one or more Laravel apps.
• You want convention over configuration and are willing to accept the package's defaults rather than tuning every knob.
• You have multiple services and value a single, consistent integration point over per-repo bespoke wiring.
• Your team is small enough that "who owns the Sentry setup" needs a cheap answer.

Look elsewhere when:

• You're not on Sentry, or are still evaluating alternatives. Choosing this package is choosing Sentry by proxy — settle the backend question first. Compare against OpenTelemetry-based approaches, Bugsnag, Rollbar, or Laravel-native Flare.
• You need deep or unusual instrumentation. Go directly to sentry/sentry-laravel. A wrapper inherently trails the upstream SDK's release cadence and feature surface, and you don't want a third party between you and a new SDK capability you need.
• You'll override all the defaults. The entire value proposition is the opinionated setup; if you're rewriting the config, you're paying a dependency cost for nothing.
• Maintenance risk is unacceptable. Single-maintainer project: check release cadence, test coverage, and — critically — whether it tracks upstream major bumps. A lag when sentry-laravel ships a breaking major turns this from convenience into a blocker. If your roadmap depends on the latest SDK, this is a soft no.

Caveat on this release: the v2.1.0 notes we received contain only a changelog URL — no described changes. Don't treat "no breaking changes documented" as identical to "no breaking changes." Read the actual v2.0.1...v2.1.0 diff before adopting or upgrading.

How to Pitch It (Stakeholders)

To executives: A small, low-risk Composer dependency that cuts the time to "first production error visible in our dashboard" from roughly half a day of configuration to a few minutes per Laravel service. It doesn't change our architecture — it's a configuration layer over Sentry. The cost is one dependency and a shallow maintenance obligation; the benefit is consistent error visibility across every service we ship, which is what turns "a customer says it's broken" into a stack trace with a release tag attached.

To engineering: If we're on Sentry, this removes boilerplate and gives us the same exception-handling setup in every repo. Keep the integration shallow — don't let product logic depend on its APIs, so we can drop it if upstream diverges or the project stalls. v2.1.0 is a minor release with no documented breaking changes; routine upgrade, review the diff, pin it, move on.