Sentry Symfony Laravel Package

Product Decisions This Supports

• Build vs. buy for observability: Whether to standardize error/performance monitoring on Sentry rather than building log aggregation, alerting, dashboards, and triage tooling in-house. The package itself is a small integration detail; the real decision is the vendor commitment and the operating practice around it.
• Reliability roadmap funding: MTTR reduction, incident detection, release health, and error-budget/SLO reporting all require an error-tracking backend to be measurable. Adopting Sentry (and a supported SDK) unlocks that workstream; deferring it means those metrics stay anecdotal.
• Support-cost containment: Production error context — stack traces, breadcrumbs, request/user data, release tagging — shortens triage and on-call time. That translates into headcount avoidance and faster customer resolution, which is the business case a PM can actually defend.
• Per-framework SDK standardization: This repository is a Symfony bundle, not a Laravel package. The decision it informs is "which Sentry SDK do we standardize on for each framework in the estate," not "should we adopt this repo." For Laravel the answer is sentry/sentry-laravel; for Symfony the official sentry/sentry-symfony.
• Fork vs. upstream supply-chain policy: With zero stars and zero dependents, this is almost certainly an agency fork of the upstream bundle. Whether the org permits third-party forks of hot-path observability libraries — and who owns patching them — is a policy decision that generalizes well beyond this one dependency.
• Use cases if the vendor decision lands: automatic exception capture at the kernel level, Doctrine/Twig/HTTP-client breadcrumbs, Monolog routing for warnings and above, user-context enrichment for support triage, release/environment tagging for regression detection, and sampled performance tracing.

When to Consider This Package

Consider it only when:

• The application is genuinely Symfony — not Laravel — on a version the bundle's constraints support, and you want bundle-level auto-instrumentation rather than hand-wiring Sentry\Client/Hub.
• Sentry is already the chosen vendor and you want the shortest path to useful data in a Symfony service.
• You can vendor-review and pin the fork, or you have confirmed it is a thin, tracking fork of upstream with a documented patch you actually need.

Look elsewhere when:

• The stack is Laravel. This bundle is built around Symfony's bundle registration, DI compiler passes, and KernelEvents listeners (kernel.request, kernel.exception, kernel.terminate). Laravel never executes that lifecycle, so automatic exception capture and breadcrumb collection silently never fire — the worst failure mode for an observability dependency. Use sentry/sentry-laravel.
• You want upstream support. Zero stars, zero dependents, and a score of 0 mean no community validation, no visible security or patch cadence, and no evidence of tracking upstream releases. Prefer the official sentry/sentry-symfony unless this fork carries a specific, documented patch.
• You need framework-agnostic coverage. For non-Symfony PHP services the base sentry/sentry SDK is the correct dependency.
• Sentry isn't decided yet. Bugsnag, Rollbar, Datadog, or an OpenTelemetry stack remain viable; picking a near-abandoned integration before the vendor call is premature.
• Procurement or compliance gates apply. A package with zero dependents will likely fail an internal dependency-risk review without an explicit, documented exception.

Minimum diligence before any adoption: check composer constraints against your PHP and Symfony LTS versions, diff against upstream to gauge drift, confirm the license, check last commit and issue responsiveness, and name an internal owner for the dependency.

How to Pitch It (Stakeholders)

To executives: We need production error visibility to cut time-to-detection and time-to-resolution on customer-facing incidents. Sentry is the buy-not-build option — it replaces bespoke logging, alerting, and triage tooling with a managed service and gives us release-level regression detection. The integration library is a small, low-cost piece of that decision; the value sits in the vendor commitment and the operating practice, not in any single package. Expect roughly a day of integration per service plus a triage runbook.

To engineering: The vendor recommendation is Sentry; the package recommendation is the official SDK per framework — sentry/sentry-laravel for Laravel services, sentry/sentry-symfony for Symfony services. gcg-it/sentry-symfony is a third-party Symfony fork with no stars and no dependents, and it will not instrument a Laravel request lifecycle. We should not put it in the dependency tree without a documented reason and an owner. If a specific fork patch is genuinely required for a legacy Symfony service, we pin it, track it, and open an upstream issue so we can return to the official bundle. Integration work is install the SDK, set the DSN per environment via secrets, wire Monolog for warnings and above, tag releases in CI, configure scrubbing so PII never leaves the process, and verify with a deliberately thrown exception in staging — a misconfigured DSN fails silently, so we confirm a real send before declaring the workstream done.