Laravel Apm Laravel Package

Product Decisions This Supports

• Build vs. buy for observability: Informs whether we instrument our Laravel monolith with a self-hosted APM package or commit to a paid SaaS vendor (Datadog, New Relic, Scout APM, Sentry). This package represents the "buy-nothing / low-cost" corner of that decision.
• Roadmap sequencing for reliability work: If we adopt it, it becomes the telemetry source for SLOs, error budgets, and post-incident reviews — which forces reliability items onto the roadmap in a measurable way rather than as ad-hoc firefighting.
• Feature-level performance baselining: Supports go/no-go calls on new features by giving us request latency, slow query, and background-job timing data before and after launch, rather than relying on anecdote ("the app feels slow").
• Use cases it fits: N+1 query detection, slow route identification, queue job failure/latency visibility, exception triage, and pre-launch load sanity checks on a single Laravel application.
• Data-governance decisions: Self-hosted telemetry keeps production data inside our infrastructure — relevant if we have data residency, PII, or vendor-security-review constraints that would stall a SaaS APM purchase.
• Buy-in economics: Lowers the threshold for "we can afford monitoring" in a cost-constrained quarter; the alternative is usually no monitoring, not a better tool.

When to Consider This Package

Consider it when:

• The application is a single Laravel monolith (not a fleet of microservices), where an in-app, Laravel-native instrumenter is sufficient.
• The team is small and PHP-fluent, can read the source, and is comfortable owning a dependency with 59 stars and a last release in Feb 2024 — i.e., we are accepting maintenance risk and may need to fork it.
• Budget for Datadog/New Relic/Scout is not approved, and the realistic alternative is shipping with no telemetry at all.
• Requirements are basic: request timing, query logging, job monitoring, a simple dashboard — not high-cardinality tracing, distributed context propagation, or anomaly detection.
• There is a compliance or data-residency reason to avoid sending production traces to a third party.
• We need something running this sprint, not after a vendor procurement cycle.

Look elsewhere when:

• Scale exceeds a single app: multi-service tracing, service maps, and distributed context require a real APM (Datadog, New Relic, Honeycomb, Grafana Tempo).
• We need mature alerting, on-call integration (PagerDuty/Opsgenie), and vendor support SLAs — this package will not provide them, and the maintainer is one person.
• Compliance/audit requirements demand a vendor with a SOC 2 report and a security review package.
• The team would have to own upgrades and security patching of an unmaintained dependency in production — a real cost that often exceeds the SaaS subscription.
• The need is actually structured logs and errors rather than APM — Laravel Telescope (dev) or Sentry (prod errors) covers that more safely.
• Traffic is trivial and Laravel Telescope in a staging environment already answers the questions we have.

Adoption criteria to gate on: a proof-of-concept on one non-critical service, an explicit decision to fork/patch if the maintainer goes quiet, a checked-in pin to a specific version, and a named engineer who owns it.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed Laravel monitoring package that gives us the basic performance and error visibility we currently lack, without a per-host SaaS subscription. It shortens time-to-diagnosis during incidents and lets us set measurable reliability targets instead of reacting to complaints. The trade-off is honest: it is a small, single-maintainer open-source project with a low community footprint, so we should treat it as a low-cost, low-commitment pilot on one service — not a platform-wide standard — and be prepared to replace or fork it if it stops being maintained.

To engineering: Laravel-native instrumentation — request/query/job timings and exceptions — configured in a few lines, self-hosted, no data leaves our infrastructure. It is not a substitute for distributed tracing or vendor-grade alerting, so we position it as baseline visibility for a monolithic app, complementing Sentry for errors and Telescope for local debugging. We pin the version, assign an owner, and evaluate an exit path before we broaden adoption.

Bottom line for the decision: Low cost of trial, low switching cost, moderate maintenance risk. Run a two-to-four week pilot on a single non-critical service with a defined success metric (e.g., median time-to-identify a slow endpoint drops from hours to minutes). Fund the pilot; do not standardize yet.