Laravel Devlogger Laravel Package

Product Decisions This Supports

• Observability spend vs. build (build-vs-buy at the low end): This package lets a team add persistent, queryable production error capture for the cost of a composer install plus a migration. It is a credible interim answer for teams who cannot yet justify Sentry/Flare/Nightwatch seat pricing, or who want error data to stay inside their own database for data-residency reasons.
• In-app error triage as a product surface: The schema is the interesting part — status (open/closed), tags, updated_by, user_id, queue, request_url. This is not just a log sink; it is a work-queue data model. It directly supports a roadmap decision like "should support/ops triage production errors inside our own admin panel instead of a third-party dashboard?" That is the decision this package most uniquely enables.
• Release-gate and QA instrumentation: onQueue() association plus request context makes it cheap to answer "did the nightly report job fail, for which user, on which queue?" — useful for deciding whether a feature is safe to ship to all tenants or needs a rollout flag.
• Support-cost reduction: User tracking + request context + captured input (with password fields excluded by default) shortens the "customer says it broke, we can't reproduce" loop. Model this as a support-tier cost decision, not an engineering one.
• Retention and compliance policy decisions: retention_days (default 30) forces an explicit answer to "how long do we keep request payloads and IP addresses?" — a GDPR/PII stance you must document. Auto-catch stores request input and ip_address/user_agent, so adopting this package is a data-protection decision, not a neutral logging tweak.
• Roadmap non-decision — no UI ships with it: The README describes "management capabilities," but the management surface is Eloquent scopes (DeveloperLog::level('error')->open()), tags, and two artisan commands. There is no dashboard, no list view, no detail screen. Any product value beyond raw capture is our build. Budget an admin panel (e.g., a Filament resource or 3–5 screens) before promising anyone a triage workflow.
• Sizing/scaling decisions: Because logs are written to the app database on every event, this packages a write-path decision into a logging choice. It pushes you to answer: does logging share the primary DB or get its own DEVLOGGER_DB_CONNECTION? For a low-traffic SaaS or internal tool this is fine; it is a roadmap constraint for anything expecting sustained high error volume.

When to Consider This Package

Consider it when most of the following are true:

• You run a monolithic Laravel 9–12 app and your team already lives in the Laravel admin panel — adding a Filament/admin resource over DeveloperLog is genuinely hours of work, not weeks.
• You want errors queryable with SQL and joinable to your own users/orders tables, and that joinability matters more to you than a polished third-party UI.
• You are pre-Series-A / small team, or the app is internal-facing, and a $0–200/month observability line item is under real scrutiny.
• You need data residency or self-hosting — logs never leave your infrastructure.
• You need a lightweight triage workflow (open → closed, tags, who closed it) rather than full alerting, APM, or trace-level performance data.
• You accept fork-and-own: MIT, small surface (a facade, a model, a migration, two commands), so if the maintainer disappears your team can vendor it.

Look elsewhere when any of these are true:

• You need alerting, tracing, or performance monitoring. This captures exceptions and messages; it does not do paging, regression detection, release health, or slow-query/span analysis. Pair it with a real tool or don't adopt it.
• Your error volume is high. Every entry is an INSERT into your primary datastore with a JSON context column and a full stack trace in longtext. Without a dedicated connection and an honest retention policy, you are risking the availability of the same database that serves customers — the failure mode is self-inflicted and embarrassing.
• You need vendor-grade maturity. 16 stars, 0 dependents, single maintainer, no stated security policy or support SLA. The patch history is instructive: v1.1.0 through v1.1.11 is a rapid run of packaging fixes (config/migration path resolution across three releases, Laravel 12 Schema::connection() signature, PHP 8.3 nullable deprecation), and v1.1.11 fixes a bug where devlogger:cleanup reported deletions but only soft-deleted rows, so retention silently never worked. Any team that had been running it was carrying a growing table with a false sense of compliance. That is the expected class of risk on a young package: correct in the happy path, thin on longevity edge cases.
• You are on Laravel 8 or older, or PHP < 8.2. Hard floor; no backport path.
• You already pay for Sentry/Flare/Nightwatch. Adding a second, weaker error store fragments the source of truth for "what is broken right now." Only adopt if the explicit goal is in-admin triage, not general observability.
• Compliance forbids storing request payloads. The default auto-catch captures request()->except(['password','password_confirmation','_token']) — every other field in a POST body lands in a JSON column. In a payment, health, or KYC context, that is likely a non-starter without a code change.

Adoption checklist before committing: set DEVLOGGER_DB_CONNECTION to a separate database (not a separate server — same server still shares connection-pool pressure), set retention_days deliberately, verify the actual row count on the table after your first devlogger:cleanup run rather than reading the command's output, restrict the log-viewing admin resource behind authorization, and add a nightly monitor that alerts if log rows grow monotonically.

How to Pitch It (Stakeholders)

One-liner for executives: A free, MIT-licensed Laravel package that saves production errors into our own database with the user, URL, queue, and request context attached — so support can triage a customer's issue without a third-party vendor and without our code or customer data leaving our infrastructure. Cost is roughly one engineer-week, including the admin screen we would build on top of it; the trade is that it is a young, single-maintainer project with no alerting and no UI, so it complements rather than replaces a real monitoring service.

The three things to say out loud:

1. Cheap and reversible. One dependency, one migration, one exception-handler hook in bootstrap/app.php. MIT and small enough to fork if it is abandoned. Deleting it is a composer remove.
2. The unique value is the join, not the logging. Errors land in the same database as our users and orders. "Which customers hit this error, and who closed the ticket" becomes a SQL query in our existing admin, not a cross-tool investigation.
3. It is a supplement, not a substitute — and it needs two guardrails. No paging, no APM, no dashboard; we build the dashboard. Guardrail one: dedicated DB connection and a retention number we actually verify, because pre-v1.1.11 cleanup silently didn't delete anything. Guardrail two: a legal review of stored request payloads before enable, because auto-catch keeps every non-password form field and the client IP.

For engineering, explicitly: treat status/tags/updated_by as the real feature — that's the triage queue — and treat DevLogger::info() in hot paths as an INSERT you are responsible for. Set excluded_paths generously, keep the exception-handler wiring the only auto-capture point, and write a one-page runbook for the cleanup command including the post-delete OPTIMIZE TABLE step the maintainer's own release notes recommend.

Recommended next step: timeboxed spike — one sprint-day to install, wire, and load a week of synthetic error volume; decide go/no-go on a dedicated connection and a PII stance. Do not adopt this as the company's answer to "we can't see production"; adopt it as "the ops team can work errors inside the tool they already use."