Elastic Apm Laravel Laravel Package

Product Decisions This Supports

• Observability strategy: Deciding whether to instrument the Laravel application with Elastic APM for distributed tracing, transaction timing, error tracking, and performance baselines — either as the primary APM or alongside existing logging/metrics.
• Build vs. buy for APM glue: This package is the “buy/borrow” option for Laravel-native Elastic APM wiring, avoiding in-house middleware, service providers, and agent configuration. Evaluate against maintaining custom instrumentation or adopting a vendor agent/SDK directly.
• Platform upgrade planning: v8.0.0 adds Laravel 13 support while dropping Laravel 11 and PHP 8.2. This directly informs roadmap sequencing: teams on Laravel 11 or PHP 8.2 must upgrade those prerequisites before adopting/upgrading this package, or defer the package upgrade.
• Feature/performance investment decisions: APM data enables prioritization of performance work, SLO definition, incident response improvements, and capacity planning — particularly for customer-facing Laravel workloads.
• Use cases: production transaction monitoring, slow query/endpoint identification, exception aggregation, cross-service tracing where Elastic APM is already the observability backend.

When to Consider This Package

Consider adoption when:

• You are standardizing on Elastic APM / Elastic Observability and want Laravel-native instrumentation without custom glue.
• You are on Laravel 12 or 13 and PHP 8.3+ (required by v8.0.0).
• You need framework-aware tracing (HTTP requests, jobs/queues, database queries, outgoing HTTP calls) faster than building and maintaining in-house middleware.
• You want a small, community-maintained integration layer rather than a heavier vendor agent, and your team can own the upgrade cadence.

Look elsewhere or defer when:

• You are pinned to Laravel 11 or PHP 8.2 — v8.0.0 drops both, so upgrade prerequisites first or stay on v7.x with a documented support window.
• You require a commercially supported APM vendor with SLAs; evaluate Elastic’s official agents/offerings or alternative APM vendors (Datadog, New Relic, Sentry, OpenTelemetry-based stacks).
• Your observability standard is OpenTelemetry and you do not want an Elastic-specific integration.
• The package’s maintenance cadence or community support does not meet your risk tolerance for a production-critical observability dependency.

How to Pitch It (Stakeholders)

For executives: This package gives our Laravel applications production-grade performance and error visibility with Elastic APM at low integration cost. The new v8.0.0 release keeps us compatible with Laravel 13, but it requires PHP 8.3+ and drops Laravel 11 — so adoption should be sequenced with our platform upgrade roadmap rather than treated as a drop-in for legacy services.

For engineering: v8.0.0 is a breaking release: Laravel 13 support added; Laravel 11 and PHP 8.2 support removed. Teams on Laravel 12/13 and PHP 8.3+ can adopt or upgrade with normal regression testing around middleware, service provider registration, and APM configuration. Teams on Laravel 11/PHP 8.2 should remain on v7.x until the platform upgrade lands, and we should track the package’s release cadence as an operational dependency. Recommend a time-boxed spike to validate tracing coverage (HTTP, queues, DB, outbound calls) and confirm it meets our observability requirements before broad rollout.