Laravel Monitor Laravel Package

Product Decisions This Supports

• Build vs. buy for observability: Laravel Monitor gives you a first-party, database-backed record of SQL statements and exceptions inside your own app — no external APM vendor, no per-host agent, no data leaving your infrastructure. This is the cheapest credible answer for teams that need "what broke and which query caused it" without signing an observability contract.
• Incident triage as a product capability: v1.7.1's Failed-badge for SQL that never fires a query event (e.g. error 1390, too many placeholders) closes a real blind spot — previously the most confusing failures were the ones the tool silently omitted. Support and on-call can now see the failing statement itself rather than inferring it from a generic 500.
• Data retention becomes a viable roadmap item: batched deletes in monitor:prune / monitor:clear (5000 rows at a time) remove the MySQL 1206 failure mode on large monitor_entries tables. This makes a scheduled prune job a safe default rather than a production hazard, which in turn makes a long-running retention policy (e.g. 30/90 days) something you can ship with confidence.
• Exception coverage expectations can be documented accurately: exceptions surfaced via the request response or a job event are now recorded even when the app's handler skips reportable() callbacks, deduplicated once per exception and gated on whether the handler would report it. This shrinks the "why isn't this in the monitor?" conversation — but note the remaining gap (below) when writing internal docs or SLA claims.
• Operational hardening over feature expansion: 1.7.1 is a fixes-only release with no migration required. Low-risk to adopt mid-sprint; supports a decision to standardize the package across services rather than treat it as a per-team experiment.

When to Consider This Package

Adopt when:

• You want query- and exception-level diagnostics stored in your own database, with no external dependency or data-egress review.
• Your monitor_entries table is large or growing and you have (or want) an automated prune schedule — 1.7.1 makes that safe.
• Your exception handling is non-standard (custom handlers, reportable() overrides, job-based flows) and you've been losing exceptions from visibility.
• You need a low-ceremony tool that a mid-level engineer can operate without an APM onboarding cycle.

Look elsewhere — or scope expectations down — when:

• You need console-command exception coverage, or exceptions your application catches and swallows itself. Both remain explicitly unrecorded as of 1.7.1; if your critical path is queue workers and artisan jobs, this is a material gap.
• You need distributed tracing, latency percentiles, or cross-service correlation — this is a per-app record store, not an APM.
• Your database is the bottleneck. Writing monitor entries into the same MySQL instance you're diagnosing adds load and lock contention precisely when the system is unhealthy; the batching fix reduces prune-time risk but doesn't change the write-path coupling.
• You require vendor-backed SLAs, long-term metric retention, or alerting/notification workflows out of the box.

How to Pitch It (Stakeholders)

To executives: This is an in-house diagnostics layer at effectively zero marginal cost — no per-seat or per-host observability spend, no vendor security review, no data leaving our environment. Version 1.7.1 makes it production-safe at scale (pruning large tables no longer fails) and closes two visibility gaps that were causing engineers to debug blind: failed SQL statements and exceptions thrown in request and job flows. It's a maintenance release with no migration and no breaking changes, so adopting it is a low-risk operational improvement, not a platform bet.

To engineering: Upgrade is drop-in — no migration. Two things change for you: monitor:prune and monitor:clear now delete in 5000-row batches, so schedule them without fear of MySQL 1206 on big tables; and failed statements plus response/job-carried exceptions now appear (Failed badge on Queries), deduplicated once per exception and only when the handler would have reported it. Known limits we should not over-promise on: console-command exceptions and exceptions your code catches and swallows itself are still not recorded. Use this for per-app triage, not as a replacement for tracing or alerting — and be mindful that it writes to the primary database.