- How do I install ntm-dev/laravel-monitor in a Laravel application?
- Install it as a Composer dependency with composer require ntm-dev/laravel-monitor, then follow the package README for publishing any config and exposing the dashboard route. The package persists data to a monitor_entries table inside your existing database, so no separate observability service is needed. Install and verify in a non-production environment first, confirming that request, query, and exception entries appear on the dashboard before rolling out.
- Which Laravel and database versions does laravel-monitor support?
- The v1.7.1 release notes explicitly reference MySQL error 1206 handling, so MySQL is a confirmed integration context. The supported Laravel version range and other Laravel-supported databases are not established by the release notes, so check the package composer.json constraints and README before adopting it. If you run PostgreSQL, SQLite, or a nonstandard queue driver, validate capture behavior in staging before a broad rollout.
- Does Laravel Monitor require a database migration?
- The v1.7.1 release notes state that no migration is required for this upgrade, and no breaking changes are indicated. A fresh install still creates the monitor_entries table through the package migration, so confirm it exists after installation. Upgrading an existing install is a standard Composer dependency bump.
- How does monitor:prune work and how should I schedule it?
- The monitor:prune and monitor:clear commands delete monitor entries, and v1.7.1 batches those deletes so large purges are less likely to hit lock-size failures such as MySQL error 1206. Schedule monitor:prune through Laravel's scheduler, typically daily, and align the retention window with your team's data and compliance expectations. Batching reduces lock risk but does not solve unbounded table growth, so still monitor monitor_entries size and keep an explicit retention policy. Test the command against a staging copy of a large table before running it in production.
- Does laravel-monitor capture slow queries and failed SQL statements?
- Yes. The package records query activity so you can spot slow queries and performance bottlenecks, and v1.7.1 closes a gap by capturing failed SQL statements that never emit query events. Failed statements surface with Failed badges on the Queries page. Validate this in staging with a deliberately malformed query, and check behavior under high-volume workloads since the capture path interacts with existing query listeners.
- Are SQL bindings stored, and is captured query data a privacy risk?
- Captured SQL may contain sensitive values, so treat monitor_entries as potentially sensitive data and restrict dashboard access accordingly. The release notes do not establish whether bindings are captured, redacted, or configurable, so review the package config file before enabling it on production data. If you handle PII or credentials in queries, confirm redaction behavior in staging before rollout.
- Which exceptions does Laravel Monitor miss?
- Console-command exceptions and exceptions your application catches and swallows are still not recorded, so the package is not a complete exception source of truth. v1.7.1 does close one observability gap by capturing exceptions carried on request and job events when reportable() callbacks are skipped. Pair it with a full error tracker if you need guaranteed exception coverage across all execution paths.
- What is the performance overhead on a high-traffic production app?
- The package is designed as lightweight, in-app observability backed by your existing database rather than an external service, so overhead is mainly write volume to monitor_entries. Because it hooks into the query and exception lifecycles, cost scales with traffic and how much SQL you capture. Benchmark against realistic traffic in staging, watch table growth, and tune retention before enabling it on busy production systems.
- Can I upgrade to v1.7.1 safely, and are there breaking changes?
- v1.7.1 is a low-risk patch upgrade: no migration is required and no breaking changes are indicated. Upgrade with a normal Composer bump in a non-production environment, then validate exception capture from HTTP requests and queued jobs, failed SQL visibility on the Queries page, and monitor:prune against a large table copy. Only then roll to production during a routine maintenance window and watch table growth and capture behavior afterward.
- How does Laravel Monitor compare to Telescope, Sentry, or New Relic?
- Laravel Monitor is a low-cost, in-app diagnostic aid rather than a replacement for APM or log aggregation tooling. It complements those tools by giving you a quick dashboard for requests, slow queries, exceptions, and uptime without wiring up external infrastructure. Use it for development, staging, and targeted production checks, and keep a dedicated error tracker where full exception coverage matters.