Weave Code
Monitor Symfony Bundle Laravel Package
quiet-guard/monitor-symfony-bundle
A Symfony bundle from Quiet Guard that adds monitoring to your application, helping you track health signals and catch issues early so production stays stable and quiet. Simple to install and configure for Symfony projects.
Symfony bundle to report exceptions and application logs to a Quiet Guard server.
Frequently asked questions about Monitor Symfony Bundle
- Does quiet-guard/monitor-symfony-bundle work with Laravel?
- No. This is a Symfony bundle and is registered through Symfony's bundle system, not through Laravel's package discovery and service provider model, even though Laravel shares Symfony components underneath. The Laravel artifact is the sibling Quiet Guard Laravel SDK. If you are running both frameworks in one organisation, pin both to the same core ^0.5.0 line so behaviour stays consistent.
- How do I install and register the bundle in a Symfony application?
- Install it with Composer using quiet-guard/monitor-symfony-bundle and register the bundle in your bundles configuration. Setup is designed to be zero-config, so monitoring starts as soon as the bundle is registered with no external infrastructure required. Before rolling out, check the PHP and Symfony framework constraints declared in the bundle's composer.json and confirm they resolve cleanly against your existing dependency graph.
- What health check endpoints does it expose?
- The bundle exposes readiness and liveness probes that you can wire into your stack's health checking, such as container orchestrators or load balancer checks. They are intended to answer whether the application can serve traffic and whether it is still alive. Because the endpoints are served by the application itself, keep their logic lightweight so probes stay fast under load.
- How do I add my own custom checks and thresholds?
- Custom checks let you plug in your own metrics and thresholds alongside the built-in tracking of response times, failures and resource usage. The bundle is Symfony-native, so your checks are wired through the container and can use events and the profiler for visibility. Start with a small number of high-signal checks and add more only when you know which thresholds actually predict incidents.
- Which Symfony and PHP versions are supported?
- Version support is defined by the constraints in the bundle's composer.json plus the constraints of the underlying core package it depends on. Release 0.5.0 is a lockstep dependency bump that requires core ^0.5.0 and changes nothing else, so the compatibility surface should be identical to the 0.4.x line. Always verify the resolved PHP and Symfony constraints with Composer before upgrading in a pinned production environment.
- Is it safe to run in production, and what is the runtime overhead?
- The bundle is described as quiet by design, with minimal overhead and alerts raised only when something is wrong. That said, it is still an observability integration, so measure runtime overhead and data volume in a staging environment before a broad rollout. A release that contains no functional change still inherits whatever the core package does, so review core behaviour when the version moves.
- Why does the changelog mention monitor:backup --exclude-table when this bundle doesn't have that command?
- That feature belongs to the Laravel SDK sibling and is not shipped by this Symfony bundle. The reference is a synchronisation artefact of a shared changelog across the multi-framework family. Do not infer feature parity from the notes; confirm capabilities against the bundle's own code and documentation before planning around them.
- Do I need to migrate anything when upgrading to 0.5.0?
- No migration is required from the 0.4.x line. Version 0.5.0 is a pure lockstep dependency bump that only raises the core requirement to ^0.5.0, leaving configuration, service wiring and runtime behaviour unchanged. Treat it as a routine maintenance refresh: batch it with other dependency updates and let your existing test suite run in CI to confirm resolution.
- The core package is still pre-1.0. How stable is it and how should I pin versions?
- While the core is on a 0.x line, semver permits breaking changes on minor version bumps, so ^0.5.0 can still surprise you between releases. Pin exact versions in production until a 1.0 stability signal appears. Also confirm the maintainer's release cadence, responsiveness and whether a security policy exists, and track the core package's changelog separately from the bundle's.
- When should I use this instead of a full observability or APM stack?
- Choose it when you want lightweight, self-hosted health signals inside a Symfony application without standing up external monitoring infrastructure. It covers response times, failures, resource usage, readiness and liveness probes, which is enough for many small and mid-sized services. If you need distributed tracing, long-term metric storage or cross-service dashboards, pair it with a dedicated observability platform rather than expecting this bundle to replace one.
Weaver
How can I help you explore Laravel packages today?