Laravel Monitor Laravel Package

Getting Started

• Install the package with composer require and publish its config/migrations (php artisan vendor:publish --tag=monitor-config / --tag=monitor-migrations), then run php artisan migrate to create the monitor_entries table. No manual schema work is needed — including after the 1.7.1 upgrade.
• Open the monitoring UI (the package exposes a Queries page and related views) and confirm entries flow in by hitting an endpoint that runs a query or throws an exception.
• First real use case: leave the dashboard open in a staging environment and watch the Queries page while exercising a slow endpoint — check for N+1 patterns and slow statements before reaching for a full profiler.
• Tune sampling/config early (enabled environments, retention) rather than after the table grows; pruning is a background concern, not a daily one.

Implementation Patterns

• Verify with artisan commands: use monitor:clear when you want a clean slate before reproducing a bug, and schedule monitor:prune in app/Console/Kernel.php (or the scheduler) to keep retention bounded. As of 1.7.1 both commands delete in 5000-row batches, so they are safe to run against large production tables without hitting MySQL error 1206.
• Reproduce failures on purpose: the Queries page now records failed SQL statements with a Failed badge. Use this during development to catch statements that never fire a query event — e.g. "too many placeholders" (error 1390) from dynamically built whereIn clauses — instead of discovering them in logs.
• Exception recording without touching your handler: exceptions carried by the request response or a job event are recorded even if your app's exception handler skips reportable(). You do not need to add manual report() calls or custom middleware to get coverage. Recording is once per exception and only when the handler would report it, so it respects your dontReport list.
• Pair with queue workers: since job-event exceptions are captured, run the monitor in the same environment as your workers to see failures that never surface as HTTP 500s.
• Local debugging workflow: reproduce → monitor:clear → hit the endpoint / dispatch the job → read the Queries and exceptions views → fix → confirm the entry no longer appears.

Gotchas and Tips

• Console and swallowed exceptions are still invisible. Exceptions thrown in artisan commands, and ones your code catches and swallows itself, are not recorded (stated explicitly in 1.7.1). If a command fails silently, fall back to logs.
• reportable() filtering still governs what appears. The new recording path only logs exceptions your handler would report — if you've added an exception to dontReport (or a reportable() return of false) and expected to see it in the dashboard, it won't be there by design.
• Batching changes prune time, not semantics. monitor:prune/monitor:clear still delete the same rows, just in chunks of 5000. On very large tables expect the command to run longer in wall-clock time; give it a generous timeout if you've wrapped it in a job or a scheduler with strict limits.
• Failed SQL is not the same as a thrown exception. Use the Failed badge to find statements the driver rejected outright; slow-but-successful statements won't carry it. Check both views when diagnosing an incident.
• Debugging missing entries: verify the environment is enabled in config, confirm the migration ran (no migration needed for 1.7.1 itself), and check that the request/job actually reached the point where the event fires — silent failures often mean the code path was never executed.
• Extension points: the config file is the place to adjust enablement and retention; prefer config over forking views. If you need custom reporting behavior, remember the package deliberately defers to your exception handler's reporting decisions.