Laravel App Logger Laravel Package

Product Decisions This Supports

• Build vs. buy for observability: This package covers the "logs I can actually look at" gap for teams without a centralized logging stack (Datadog, Sentry, CloudWatch, Papertrail). It persists application logs to the database and ships a browsable dashboard, so the decision is usually adopt rather than build a custom log viewer.
• Supporting-environment roadmap: Database-backed logging matters most where filesystem logs are ephemeral or inaccessible — shared hosting, containerized apps without persistent volumes, small ops teams without log aggregation. This informs platform and hosting decisions.
• Audit and traceability features: Request/exception history in a queryable store supports customer-support investigations, incident timelines, and lightweight audit requirements without standing up new infrastructure. Relevant to roadmap items like "support can self-serve error lookups."
• Compatibility and upgrade planning (v1.3.0): Laravel 13 support means the package is not a blocker in a framework-upgrade roadmap. This is a concrete input to "can we schedule the Laravel 13 upgrade this quarter?" — a maintained dependency lowers the cost and risk of that initiative.
• Maintenance-cost and dependency-risk decisions: A small, single-maintainer package is low-cost to adopt but is a dependency to track. This informs whether to wrap it behind an internal interface so it can be swapped later.
• Scope decisions to defer: Choosing this package lets the team defer investment in full observability tooling until volume, compliance, or multi-service needs justify it.

When to Consider This Package

Good fit when:

• You run a Laravel monolith or small set of apps and want searchable logs without new infrastructure or vendor contracts.
• Your team lacks a log-aggregation pipeline, or logs are lost on deploy/restart.
• Support or ops staff (non-engineers) need a UI to look up what happened for a given request or user.
• You need a low-effort audit trail for a compliance-adjacent or dispute-resolution requirement.
• You are planning a Laravel 13 upgrade and want dependencies confirmed compatible (v1.3.0 addresses this directly).

Look elsewhere when:

• You already run a mature observability stack; this would be a duplicate, and database logging adds write load to your primary DB.
• You operate high-traffic or high-cardinality workloads — writing every log row to the application database can contend with production traffic and needs retention/purge policies.
• You need distributed tracing, metrics, alerting, or cross-service correlation — this is a log viewer, not an APM.
• You require vendor-backed SLAs or an enterprise support contract; this is a community package with a single primary maintainer.
• You have strict data-residency/PII rules that make it simpler to keep logs out of the primary datastore entirely.

Adoption guardrails to decide up front: retention window and purge job, what gets logged (avoid capturing sensitive payloads), separate database connection if write volume is a concern, and access control on the log dashboard.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source addition that gives us searchable application logs and a dashboard without buying an observability platform. It closes a real operational gap — right now, when something goes wrong, finding out what happened depends on whoever can reach the server logs. The latest release (v1.3.0) adds Laravel 13 support, which means adopting it now does not put our framework upgrade at risk. Cost is engineering time to install and configure, plus ongoing attention to log retention; there is no license fee and no vendor lock-in.

For engineering: Adopt kitloong/laravel-app-logger as our interim, database-backed logging and log-viewing layer. It provides a queryable log store plus a browsable UI, which is meaningfully better than tailing files for a small team. v1.3.0's only change is Laravel 13 compatibility, so it's a safe bump with no breaking changes. Two caveats: keep it behind a thin internal interface so we can replace it with a hosted observability tool later without touching call sites, and configure a retention/purge policy plus a separate DB connection if log write volume is non-trivial. Treat it as a bridge, not our long-term observability strategy — if we outgrow it (multi-service tracing, alerting, metrics), we migrate rather than extend it.