Laravel Metrics Laravel Package

Product Decisions This Supports

• Observability build-vs-buy. The package is thin glue: it listens to Laravel events you already dispatch and forwards counters/gauges to a backend. That reframes the decision from "do we build a metrics pipeline?" to "do we spend a day writing driver code we'd otherwise duplicate in every service?" For most teams the honest answer is that this is a ~1-day build, so the buy case rests on the multi-backend abstraction, not on novel capability.
• Deferring the observability vendor decision. Because one config file fans out to InfluxDB, Prometheus, CloudWatch, or PostHog, you can ship instrumentation now and swap or dual-write backends later. This is the single strongest product argument: instrumentation is the expensive, sticky part; the sink is replaceable.
• Feature adoption and roadmap prioritization. The PostHog driver lets product events double as adoption metrics without standing up a separate analytics SDK. Useful for "did anyone use the thing we shipped?" questions that gate the next quarter's roadmap.
• SLOs, error budgets, and capacity planning. Domain events (order placed, job failed, webhook rejected) become time series with no new application code. Supports launch-readiness reviews and on-call thresholds.
• Usage-based packaging and plan-tier design. Event counts per tenant are a reasonable input for tier design and internal dashboards — but see the caveat below: this is not a billing meter.
• Standardizing instrumentation across a portfolio. For an org with several Laravel apps, a shared package-plus-convention beats five bespoke StatsD::increment call sites with divergent naming.

Caveat that should shape the decision: with ~50 GitHub stars, this is a low-adoption dependency. That's tolerable for a small, MIT-licensed adapter with a narrow surface area, but it means you are partly the maintainer. Budget for pinning the version and being prepared to fork — and avoid it on any path where metric loss would be a revenue or compliance event.

When to Consider This Package

Adopt when most of these hold:

• You're on Laravel and already emit domain events — the integration cost approaches zero.
• You need more than one sink, or expect to change sinks. Single-backend shops get less value from the abstraction.
• You want ops metrics and product analytics from one instrumentation pass (Prometheus/CloudWatch plus PostHog).
• Your team is small and the alternative is nobody instrumenting anything. A working, boring pipeline beats a perfect unbuilt one.
• You accept the maintenance risk and can pin, vendor, or fork a few hundred lines.
• Your metric needs are simple: counters and gauges tied to discrete events.

Look elsewhere when:

• You need distributed tracing, spans, or high-cardinality analysis. Reach for OpenTelemetry; this package won't get you there, and adopting both means two instrumentation layers.
• You need histograms, native percentiles, or client-side aggregation. Confirm driver support before committing — the least-common-denominator across four backends is unlikely to be rich.
• Accuracy is financially or legally load-bearing. Event-driven shipping typically lacks delivery guarantees, dedupe, and replay. Do not meter invoices with it; use a purpose-built billing meter.
• You're already standardized on OTel or a vendor agent. Adding a second pipeline is pure overhead.
• You need vendor support, SLAs, or a large community. Fifty stars means Stack Overflow won't save you.
• You're not on Laravel, or you're on an old major version the package doesn't track.

Also flag the cardinality trap during evaluation: tagging metrics with user ID, tenant ID, or request ID will wreck InfluxDB and run up CloudWatch bills fast. Decide the allowed tag set before rollout, not after the first invoice.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed adapter that turns the events our application already fires into metrics, with one config switch to send them to InfluxDB, Prometheus, CloudWatch, or PostHog. It buys us instrumentation speed and vendor flexibility for roughly the cost of a day of engineering, with no new infrastructure and no license spend. The trade-off is maturity: it's a niche package, so we treat it as code we may need to own — which is cheap at this size. Recommend a scoped pilot on one service, not a platform-wide mandate.

To engineering: One package, one config file, one listener convention. You keep dispatching the events you already dispatch; the package maps them to metrics and hands them to a driver. It's a thin abstraction over well-understood clients, so the blast radius is small and forking is realistic. Two asks before we commit: agree a bounded tag/label set to keep cardinality sane, and confirm the drivers we care about support the metric types we actually need. If you'd rather go straight to OpenTelemetry, say so now — that's a legitimate "no" and I'd rather hear it before we instrument twice.