Weave Code
Inspector Symfony Laravel Package
inspector-apm/inspector-symfony
Symfony bundle for Inspector APM that adds real-time error tracking and performance monitoring to your application. Capture exceptions, slow requests, SQL queries, and background jobs, then inspect and debug issues from a single dashboard.
Connect your Symfony application to the Inspector monitoring dashboard.
Frequently asked questions about Inspector Symfony
- Can I use inspector-apm/inspector-symfony in a Laravel application?
- No. inspector-apm/inspector-symfony is a Symfony bundle, not a Laravel package. It registers a Symfony Bundle class, hooks kernel.request, kernel.exception and kernel.terminate, and wires Doctrine middleware through the Symfony DI container. Laravel does not expose those extension points, so installing it in a Laravel app gives you little or no working auto-instrumentation.
- What Laravel versions does this package support?
- None. The package targets Symfony, not Laravel, so there is no Laravel version compatibility to check. For Laravel you should evaluate the vendor's first-party inspector-apm/inspector-laravel package or build on the framework-agnostic inspector-apm/inspector-php client. Confirm supported PHP, Symfony and Doctrine versions on Packagist before planning.
- How do I install and configure Inspector in a Symfony app?
- Install it with Composer using composer require inspector-apm/inspector-symfony, enable the bundle in your Symfony application, and provide your Inspector ingestion key through configuration or environment variables. Setup is intentionally minimal with low overhead. Restart the application and verify transactions appear in the Inspector dashboard.
- What does Inspector automatically monitor in a Symfony application?
- It automatically captures HTTP requests, exceptions with stack traces, database queries through Doctrine, and Symfony Messenger background jobs. It is designed to surface slow endpoints, inefficient SQL and N+1 query patterns, and errors with contextual data. All of this is viewed from a single Inspector dashboard rather than custom infrastructure.
- How much overhead does Inspector add to production requests?
- APM agents sit on the request hot path, so overhead depends on sampling, payload capture and transport behavior. Inspector buffers data and flushes around kernel.terminate, but you should benchmark with your own traffic and review sampling defaults before production. Also test the failure mode when the ingestion endpoint is unreachable: confirm whether it silently drops, buffers to disk, or adds latency.
- Does Inspector monitor Symfony Messenger background jobs and long-running workers?
- Yes, the bundle includes background job monitoring for Symfony Messenger consumers. That said, auto-instrumentation packages are sensitive to runtime model, so verify per-job transaction boundaries, buffer flush intervals and memory growth in long-running workers. Do not assume request/response lifecycle assumptions hold in resident worker processes.
- What data does Inspector capture, and how do I prevent PII or sensitive SQL from leaving my app?
- The overview does not document exactly what is captured by default, so treat request bodies, headers and SQL bindings as items to verify during a proof of concept. Review the configuration for redaction controls and disable payload capture where necessary. Sending production data to a third-party SaaS is also a procurement and data-residency question, not just a code setting.
- How can I test Inspector without sending data to the SaaS or affecting tests?
- The public overview does not describe a test mode or fake transport, so confirm this in the source before relying on it. A practical approach is to disable Inspector in test and local environments, or isolate the framework-agnostic inspector-php transport behind an interface you can stub. Do not let tests send real transactions to the hosted service.
- Is inspector-symfony actively maintained and safe to adopt?
- Adoption signals are weak: the repository has roughly 28 stars and zero Packagist dependents, so there is little third-party production validation. The client code is MIT and forkable, but the backend is a commercial SaaS you cannot self-host. The listed last release date also warrants verification against Packagist before you plan around the vendor's cadence.
- What should Laravel teams use instead of inspector-symfony?
- For Laravel, use inspector-apm/inspector-laravel if you want the same vendor, dashboard and data model, or build directly on inspector-apm/inspector-php if you need custom instrumentation. Laravel Telescope is useful for local debugging but is not a hosted production APM. Sentry or other APM vendors are alternatives if you mainly need error tracking and performance traces.
Weaver
How can I help you explore Laravel packages today?