Laravel Route Statistics Laravel Package

Product Decisions This Supports

• Feature investment & roadmap prioritization. Route-level usage counts (with user_id, team_id, timestamps, and aggregation by minute/hour/day/month) give a defensible answer to "who actually uses this screen?" — turning feature sunset/scale-up debates from opinion into evidence.
• Deprecation and dead-code decisions. The bundled route:unused command lists every route with zero logged hits, producing a ready-made candidate list for removal. This is the single highest-ROI use of the package for a maturing product: it converts an engineering cleanup backlog into a prioritized, evidence-backed one.
• Adoption, activation, and engagement instrumentation. Because records capture the authenticated user and an optional team_id context, you can build cohort/activation reporting ("did the account touch the core workflow in week one?") without buying a product-analytics suite or adding client-side tracking.
• API quota, packaging, and monetization inputs. whereApi / whereWeb query scopes plus per-route volumes let you see which endpoints or surfaces tenants lean on — useful for pricing-tier design, overage policy, and deciding whether an integration deserves a dedicated plan.
• Abuse, scraping, and cost-of-service detection. High request counts from unauthenticated users (IP + status code + volume) surface bot traffic and hot endpoints before they become an infrastructure bill or an incident.
• Capacity planning and caching/performance bets. Relative route volumes plus status codes justify where to invest in caching, queueing, or database indexing — "this endpoint is 40% of traffic" is a strong roadmap argument.
• Build vs. buy. This package replaces "write our own request-logging table and middleware" (roughly a week of engineering plus permanent maintenance) with a Composer install, one publishable migration, and a config file. It is not a replacement for an APM/observability vendor — see below.

When to Consider This Package

Consider adopting when:

• The product is a Laravel 10/11/12/13 application on PHP 8.2–8.5 (v4.x covers this matrix and the maintainer has shipped compatibility releases promptly through Laravel 13 and PHP 8.5).
• The questions you need answered are usage-shaped, not latency-shaped: "which routes matter," "who uses what," "what's unused," "which tenants are heavy." Full request tracing is a different tool.
• Budget or procurement is a constraint. MIT license, no seats, no per-event pricing, no vendor security review. This is a genuine advantage for internal tools and early-stage products.
• Data residency or privacy posture argues against shipping request metadata to a third-party SaaS. Everything stays in your own database, and you control retention.
• Traffic is moderate and you can accept write amplification. The package mitigates this with aggregation (second/minute/hour/day/month) so the table stays small, and it supports queued logging (since v2.1.0) to take the write off the request path.
• You want a stepping stone: log now, decide later whether to graduate to a full observability stack. The underlying logger is a separate package with a swappable contract.

Look elsewhere when:

• You need distributed tracing, latency percentiles, error grouping, or alerting. This package records counts and outcomes; it will not tell you why a request was slow.
• You need a product-analytics-grade model — funnels, retention curves, event properties, session stitching, warehouse sync. Route hits are a coarse proxy for user behavior and will not survive contact with a growth team's questions.
• Compliance surface is tight. The default logger persists IP addresses and user identifiers. If you operate under GDPR/CCPA with a strict minimization stance, you are taking on a lawful-basis and retention-policy obligation, plus DPO review. Plan for a redaction strategy and a purge schedule before, not after, enabling global logging.
• Traffic is very high and writes are already the bottleneck. Even queued and aggregated, this is another write per request class. Verify against your peak-load headroom.
• The ecosystem-risk tolerance is low. 238 stars, effectively a single maintainer, and zero dependent packages is a real signal: this is a well-maintained personal-scale library, not a widely battle-tested piece of infrastructure. There is no third-party ecosystem to absorb the maintenance burden if it stalls.
• The application isn't Laravel, or the team standardizes on a platform-native analytics/observability service for governance reasons.

How to Pitch It (Stakeholders)

One line: A small, free, MIT-licensed Laravel package that records which routes our app actually uses, per user and per team, so we can make roadmap, deprecation, and pricing decisions on evidence instead of guesswork — with all data staying in our own database.

For executives — the business case: We currently cannot confidently answer "is anyone using this feature?" or "which parts of the API do our biggest customers depend on?" We can either buy a product-analytics/observability platform (recurring cost, procurement, security review, data leaving our perimeter) or install an open-source package in an afternoon. This gives us the 80% answer — route-level usage, per-user and per-team, over time — for near-zero cost and no vendor. The immediate deliverable is a ranked list of unused routes and features, which is a direct, defensible input to reducing maintenance surface and infrastructure spend.

For engineering — the honest trade-off: Installation is a Composer require, one published migration, and one config file. Enabling is a single line in bootstrap/app.php, a routestatistics route middleware, or an ad-hoc $request->routeStatistics() call inside a controller for conditional cases. It writes one row per request into our own database, with optional aggregation by second/minute/hour/day/month plus a purge path, and supports queued logging so we don't add latency to the hot path. It captures user_id, team_id, method, route, parameters, status, IP, and timestamp — so we own the privacy decision: scoping, IP suppression, and retention are configuration, not vendor terms.

For the risk register: Low lock-in, low switching cost — the logging contract is an interface we can reimplement or replace. The real risks are (1) single-maintainer, zero-dependents project maturity, mitigated by MIT license and a small, readable codebase we can fork if needed; (2) privacy obligations from storing IPs and user IDs, which we address with scoped middleware and a retention job; and (3) it being mistaken for observability tooling — it explicitly is not, and we should say so before someone expects dashboards and alerts.

Recommendation: Adopt in a scoped pilot, not globally. Enable via route middleware on two or three route groups where a real decision is pending (one candidate for deprecation, one high-traffic API surface), pair it with a retention job and an IP-handling decision, and review route:stats / route:unused output after 30 days. Expand only if the data changes a decision.