Sentry Bundle Laravel Package

Product Decisions This Supports

• Observability feature gap: This package exists to answer "do we know when production breaks?" It auto-registers an exception handler inside the framework so uncaught errors are shipped to a Sentry server — that is the first rung of an error-monitoring capability, above raw logs and below full APM.
• Build vs. buy vs. borrow: The underlying decision is don't hand-roll error capture — use an SDK. But this specific artifact turns that into a three-way choice: upstream kunstmaan/sentry-bundle, this Practo fork, or a modern maintained SDK. The fork only wins if its "minor modifications" map to a problem you actually have.
• Incident response / MTTD-MTTR roadmap: Error aggregation with stack traces, release context, and alerting directly supports reducing mean-time-to-detect. Useful to cite when sizing on-call and incident tooling work.
• Legacy portfolio triage: With zero stars, zero dependents, and a Symfony2-era raven-php foundation, this signals a maintenance decision more than a feature decision — is the owning app still worth investing in, or is it on a sunset path?
• Vendor standardization: Choosing this reinforces Sentry as the error-tracking vendor. That has downstream consequences for alerting, PII scrubbing policy, retention, and cost-per-event modeling — worth deciding explicitly rather than by default.
• Framework-appropriateness check: This is a Symfony2 bundle, not a Laravel package. It is not applicable to a Laravel codebase; for Laravel the equivalent decision is sentry/sentry-laravel.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining an existing Symfony2 application (not Laravel, not Symfony 3.4+) that already depends on Kunstmaan bundles.
• The environment is pinned such that the modern sentry/sentry Symfony SDK cannot be installed (old PHP, locked Symfony version).
• You have reviewed the diff against upstream and the Practo modifications solve a concrete problem you have — otherwise use upstream directly.
• You accept that support is effectively self-support: no community, no issue traffic, no dependents to lean on.

Look elsewhere when:

• Any Laravel project — use the official Laravel SDK; this bundle's service-container and autoload conventions won't fit.
• Any new or actively developed service — raven-php is deprecated and superseded by the unified sentry/sentry SDK; starting here means planning a migration on day one.
• You need a maintained dependency — 0 stars / 0 dependents / a fork of a fork means you are the maintainer.
• You have compliance or vendor-support requirements (SOC2 evidence, security patching SLAs) — an unmaintained fork will not satisfy this.
• You need modern Sentry capability — performance tracing, breadcrumbs, release health, and sampling are not well served by this generation of integration.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed patch that gets production error alerts out of a legacy Symfony application and into Sentry. The upside is cheap visibility and faster incident detection; the downside is that nobody maintains it — it is a fork with no users, built on a deprecated library. Treat it as a tactical stopgap for one legacy service, not a platform standard. It creates no meaningful lock-in; Sentry is swappable, and the exit cost is a small integration rewrite.

For engineering: It autoloads a Sentry-backed exception handler into the framework with minimal configuration, so uncaught exceptions get reported without per-controller instrumentation. Two caveats to plan around: (1) it is Symfony2-only and does not apply to our Laravel services, which should use the official SDK; (2) it sits on raven-php, which is end-of-life, so adopting it should come with a tracked migration ticket to sentry/sentry. Recommendation: use it only if we're keeping the legacy Symfony app alive for a defined window; otherwise don't adopt — instrument with the current SDK or retire the service.