Logs Laravel Package

Product Decisions This Supports

• Performance roadmap prioritization. Query-level visibility is an input to the "do we invest in caching, queueing, read replicas, or index tuning?" decision. Logging routines and SQL gives you the evidence to rank those bets by actual cost rather than intuition.
• Build vs. buy for observability. Query/routine logging is commodity capability, not differentiation. The real decision this package informs is whether to (a) adopt an off-the-shelf logger, (b) lean on first-party Laravel tooling, or (c) write a ~150-line internal wrapper around DB::listen plus a log channel. The package's existence is a data point that the capability is small enough to be packaged — which argues against paying much for it, in engineering time or in dependency risk.
• Incident response and support cost. Time-to-diagnose is a support-cost line item. Routine and query traces shorten escalation paths on N+1 regressions, scheduler failures, and slow-endpoint tickets. This supports decisions about on-call tooling budgets and whether to staff a platform/DX function.
• Pre-launch and migration audits. Useful decision support for "is this ORM change safe to ship?" and "did the Laravel upgrade introduce query regressions?" — discrete, time-boxed questions rather than permanent dependencies.
• Compliance and audit posture. Routine logging can feed audit trails for scheduled jobs, but it also creates a PII/secret-retention decision: query bindings routinely contain emails, tokens, and customer data. Any adoption decision is simultaneously a data-handling decision that needs legal/security sign-off, not just an engineering one.
• What it should not anchor. With zero stars, zero dependents, and no ecosystem validation, this package cannot support a platform-level commitment. Treat it as a candidate for a spike, never as the foundation of an observability strategy.

When to Consider This Package

Consider it only when all of the following hold:

• The need is short-lived and diagnostic — a profiling sprint, a migration audit, a one-off production investigation — not a permanent production dependency.
• You can vendor it or pin it to an exact commit, read the source, and accept ownership of it. Assume you are forking it, because there is no evidence of a maintenance community behind it.
• You have verified, by reading the code, that it supports: configurable log channels, sampling or rate limiting, redaction or exclusion of query bindings, and bounded memory/IO overhead under load.
• Your Laravel version is explicitly covered by the package, and you have a tested upgrade path.
• The environment is internal, low-traffic, or a non-regulated side project where a surprise breakage is cheap.

Look elsewhere when:

• Production or high-traffic systems. Use Laravel's native DB::listen, Laravel Telescope, Clockwork, or OpenTelemetry exported to Sentry/Datadog/New Relic. These have vendor backing, security response processes, and documented overhead characteristics.
• Security and compliance matter. Zero stars and zero dependents mean no CVE coverage, no disclosure channel, and a bus factor of one anonymous maintainer. Logging query bindings is a direct path to leaking credentials and personal data into log storage.
• You need durable support. No semver guarantees, no changelog credibility, no issue-tracker activity to gauge responsiveness.
• You need more than query text — traces, spans, exception correlation, or dashboards. This is a narrow utility, not an APM substitute.
• The logging volume itself is the problem. Logging every query at scale can cost more in storage and I/O than the inefficiency you're hunting; sampling and aggregation are the answer, and this package is unlikely to be the right vehicle.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a recurring, expensive class of problem — slow endpoints and failing scheduled jobs that take too long to diagnose. A package like litermi/logs addresses that need by recording routine and SQL activity. The capability is worth having; this specific package is not yet a safe dependency. It has no stars, no downstream users, and no visible maintainer community, which means no security response path and a real chance we inherit it as an unmaintained fork. My recommendation is not to adopt it as-is: run a two-day evaluation to confirm whether its redaction and overhead characteristics are acceptable, and in parallel default to Laravel's built-in tooling. Expected cost of the recommended path is under a week of engineering, versus an open-ended maintenance and data-leak liability.

To engineering (the working ask):

• Spike, don't commit. Time-box two days. Install on a branch behind a config flag, exercise it against a representative workload, and record: per-request overhead, log volume per 1k requests, behavior with bindings containing credentials/PII, and compatibility with our Laravel version.
• Read the source before it touches a lockfile. Verify output escaping, channel configuration, and whether query bindings can be disabled or masked. If raw bindings are written by default, that is a blocker, not a config tweak.
• Benchmark against the native alternative. DB::listen plus a dedicated log channel, or Telescope in non-production, likely covers 80% of the need with zero supply-chain risk. If our own wrapper is comparable in effort to auditing this package, build the wrapper — we own it, we can version it, and we can redact by default.
• If adopted, pin hard. Exact version, committed lockfile, a named internal owner, a documented removal date, and a written note in the risk register. No transitive expansion, no auto-updates.
• Never log unbounded in production. Sampling, retention limits, and a redaction list are prerequisites, not follow-ups. Treat the log store as a system holding personal data and scope access accordingly.

Bottom line: the problem is real and worth solving this quarter; this package is a candidate input to the evaluation, not the answer. Decide on the capability, then choose the smallest, best-supported implementation — which, on current evidence, is probably not this one.