App Metrics Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy on application telemetry. Rather than hand-rolling a metrics exporter or paying for a hosted APM tier just to get request timings and custom counters, this package supplies the wiring layer (service provider, facade, middleware, Prometheus-format endpoint) under an MIT license. That converts an observability line item into an afternoon of integration work plus ongoing upgrade hygiene.
• Roadmap sequencing around the Laravel upgrade. The package's minimum is now Laravel ^11.0 and it advertises Laravel 13. That makes it a follower dependency, not a driver: it should be folded into an existing framework upgrade programme, never used to justify starting one. For a PM, this is a planning input — "we cannot take metrics package upgrades until we leave Laravel 10."
• Deciding whether to standardise on Prometheus/OpenMetrics. Because the endpoint emits a Prometheus-compatible format, this is effectively a low-cost bet on the Prometheus ecosystem (Prometheus, VictoriaMetrics, or any OpenMetrics backend) as the observability substrate. That choice is stickier than the package itself and deserves explicit sign-off.
• Scoping the first observability increment. The built-in middleware (request timing, status-code counters) plus facade helpers let you ship a meaningful v1 — latency and error-rate visibility per route — without instrumenting domain code. Custom counters, gauges, and histograms from jobs and console commands become a phase two.
• Feature-level prioritisation. Instrumentation is cheap to add and cheap to regret. PMs should require metric additions to come with a named decision they inform (SLO, capacity trigger, rollout gate) so the endpoint doesn't accumulate unused cardinality.
• Risk acceptance on a low-adoption dependency. Four GitHub stars and a single-maintainer signal mean this is a low-community-support component. A PM should consciously decide whether the blast radius (metrics unavailable, not user-facing) is tolerable — it usually is, which is precisely why it's a defensible buy-versus-build shortcut.

When to Consider This Package

Adopt when:

• The application is on Laravel 11, 12 or 13 and PHP matches the package's declared runtime constraint.
• You already run, or have decided to run, a Prometheus-compatible scraper; without a scrape target, the endpoint is dead weight.
• You need request-level and lightweight custom metrics — latency, status codes, queue/job counters — not distributed tracing, log aggregation, or deep profiling. This package complements a tracing stack; it does not replace one.
• Your team is fluent in Laravel and Composer and can absorb a constraint-raising release roughly annually as Laravel's major cadence advances.
• The metrics outage failure mode is acceptable: loss of visibility, not loss of service.

Look elsewhere when:

• Laravel 10 or earlier. Do not attempt v2.10.0. Pin to the last compatible release, finish the framework upgrade, then lift the pin.
• You need vendor-supported SLAs, security backport guarantees, or a support contract. A single-maintainer MIT package cannot supply these; a commercial APM or OpenTelemetry-based stack can.
• OpenTelemetry is the strategic standard. If tracing is or will be mandatory, standardise on OTel instrumentation and avoid running two parallel observability idioms.
• High-cardinality or business-critical analytics are required — user-segmented funnels, per-tenant dashboards, retention analysis. A Prometheus endpoint is the wrong substrate for that class of question.
• The estate is large and heterogeneous. A package that invalidates Laravel 10 affects every service still on it; treat it as a portfolio-level item, not a per-repo chore. If you cannot coordinate the fleet, defer.

Additional PM-level cautions worth resolving before approval:

• Semver reliability. Dropping Laravel 10 shipped as a minor (2.10.0) under a permissive ^2.0 constraint risks Composer resolution failures or runtime incompatibility. Pin exact versions and review changelogs; assume 2.x is not reliably semver.
• Laravel 13 support may be declarative only. Ask whether there is real CI coverage against 13 or just a constraint bump, and confirm 13 is GA in your environment.
• Dev/prod parity drift. The Docker image moved to PHP 8.5; confirm the package's runtime PHP constraint was raised in step, or you inherit a false sense of compatibility.
• Transitive dependency deadlock. Check the full graph resolves, especially packages lagging on Laravel 13 or capping PHP below what you run.

How to Pitch It (Stakeholders)

To executives: We can get baseline application observability — per-route latency and error rates, plus custom business counters — for the cost of a Composer dependency and a short integration spike, rather than a per-host APM subscription. The trade-off is deliberate: it is a small, MIT-licensed, single-maintainer package with no support contract. Its failure mode is losing visibility, not losing customers, so the risk is contained. The real commitment is not the package, it's the standing decision to run a Prometheus-compatible metrics backend — that is the choice worth your attention, and this package is the cheapest way to exercise it.

To engineering: Standard Composer install, auto-discovered service provider, publishable config, and a Prometheus-format endpoint ready to scrape. Middleware gives you request timing and status-code counters out of the box; a facade exposes counters, gauges and histograms from controllers, middleware, jobs and console commands. Two caveats to plan around. First, v2.10.0 requires Laravel ^11.0 — services on Laravel 10 must pin to the prior release and ride the existing upgrade, not this package. Second, the Laravel 10 removal shipped as a minor release, so pin exact versions and read changelogs; treat 2.x as non-semver until a major formalises the change. Sequence it as: audit installed versions, pin, upgrade Laravel on one representative service, bump the constraint in a branch, validate in staging, then roll out per service. Confirm the runtime PHP constraint matches production before rollout, and treat Laravel 13 as a candidate only once 13 is proven in our environment and CI coverage is verified — not merely declared.