Newrelic Bundle Laravel Package

Product Decisions This Supports

• APM vendor commitment / standardization: Adopting this bundle is a downstream signal that we've chosen New Relic as our APM of record for PHP services. That's the real decision — the bundle itself is a thin convenience layer on top of the New Relic PHP agent. If we're not already paying for New Relic and running its agent on every host, this package has no job to do.
• Build vs. buy for instrumentation glue: The core question is whether we hand-roll transaction naming, custom attributes, and ignore-rules in each Symfony service, or adopt a config-driven bundle so product-relevant signals (checkout latency, queue consumer duration, tenant IDs on traces) are declared in YAML instead of scattered across service code. This bundle is a candidate for that "buy" slot.
• Feature instrumentation beyond the defaults: The agent gives us request-level timing for free. What it doesn't give us is product telemetry — naming Messenger consumers as distinct transactions, attaching order/tenant/customer-tier context to traces, suppressing health checks and webhook noise so dashboards aren't polluted. That's the gap a bundle like this fills, and it's the gap that determines whether APM data is actually usable in roadmap and reliability reviews.
• Roadmap scoping for observability work: Committing to New Relic-specific instrumentation is a fork in the road. It makes future migration to OpenTelemetry a re-instrumentation project rather than a config change. That trade-off belongs in the roadmap conversation, not in an engineer's pull request.
• Concrete use cases worth validating: custom transaction naming for async workers, business-KPI custom events (e.g., "quote generated", "payment captured") alongside technical metrics, log-trace correlation for incident triage, and noise suppression on probe/health endpoints.

When to Consider This Package

Adopt-consider criteria:

• You are a Symfony shop. The package is explicitly a Symfony bundle. Any Laravel or framework-agnostic PHP estate is out of scope — treat the "Laravel/PHP package" framing as a category error and score it on Symfony merits only.
• New Relic is already the standard. Agent installed, license provisioned, dashboards and alerts already built. Retrofitting an APM vendor to justify a bundle is backwards.
• You need New Relic-native semantics, not just spans: custom events, newrelic_name_transaction, newrelic_add_custom_parameter, and distributed-trace header propagation across Symfony's HTTP client and Messenger. Generic OpenTelemetry instrumentation covers traces well but is clumsier for New Relic's event and NRQL model.
• You want a small, readable, MIT-licensed layer you're willing to vendor or fork. With 2 stars, 0 dependents, and a single publishing org, treat this as source you adopt, not a dependency you consume. Budget a day to read it end to end and to own it thereafter.

Look elsewhere when:

• You need a supported, battle-tested bundle. ekino/newrelic-bundle is the de facto community standard for Symfony and has the install base, issue history, and Symfony-version coverage this package does not. Absent a specific reason to prefer Tiime's, ekino is the lower-risk default.
• Vendor neutrality matters. If a future APM migration is plausible within 18 months, instrument with OpenTelemetry (open-telemetry/symfony-sdk-bundle) and export to New Relic via OTLP. You lose some New Relic-native sugar and gain an exit.
• You can't run the PHP agent. Shared hosting, restrictive container images, or a platform team unwilling to run a per-host daemon kills the value proposition entirely.
• Zero-dependency risk tolerance. A near-zero-adoption package with a single release cadence and no downstream consumers is a maintenance liability. If your org requires security review, SBOM provenance, or a support SLA, this won't clear the bar — and shouldn't be forced through it.
• You only want request timing. The base agent already auto-instruments that. Adding a bundle to get defaults you already have is pure overhead.

Recommended posture: timeboxed spike, not foundational dependency. Two engineer-days to evaluate against ekino and raw-agent autoconfiguration, with an explicit exit criterion (does it cleanly instrument Messenger consumers and let us tag business KPIs without patching?). If yes, vendor the code into an internal package. If no, default to ekino or plain agent config.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed Symfony add-on that makes our New Relic monitoring reflect our business rather than generic HTTP timing — so an on-call engineer can tell within seconds whether a latency spike is a payment path, a background job, or a health-check artifact. It is not a new vendor and not a new cost center; it only matters if we've already committed to New Relic. The honest caveat: it has almost no adoption (2 stars, 0 dependents, one publisher), so we should treat it as code we adopt and own, cap the evaluation at a couple of engineer-days, and fall back to the established community bundle if it doesn't clearly earn its place. Low cost to try, low cost to abandon — the decision it informs (New Relic vs. OpenTelemetry for PHP) is the one worth spending management attention on.

To engineering (the substance): It's a thin config-and-compiler-pass layer over the New Relic PHP agent — transaction naming, custom parameters/events, ignore rules, and HTTP client / Messenger trace propagation, configured declaratively instead of hand-wired per service. Two constraints to internalize before we invest: (1) it's Symfony-only, so our Laravel services get nothing from it; (2) with 0 dependents and a single publishing org, we must vendor or fork it rather than float on it, and we own upgrades. The evaluation is a bake-off against ekino/newrelic-bundle and against plain agent autoconfiguration — judged solely on whether it lets us name Messenger transactions and attach tenant/KPI context without monkey-patching. If it doesn't beat ekino on that narrow test, we take ekino and move on. Separately, flag for the platform conversation: any New Relic-specific instrumentation deepens our APM commitment and makes an OpenTelemetry migration a re-instrumentation effort — decide that deliberately, not by default.