Weave Code
Bundle Health Check Laravel Package
oat-sa/bundle-health-check
oat-sa/bundle-health-check provides configurable health and readiness checks for PHP applications. It exposes diagnostic endpoints, verifies dependencies and service availability, and reports clear status for monitoring, load balancers, and orchestration tools so operators can detect failures early.
Symfony bundle for health checks automation, based on health check library
Frequently asked questions about Bundle Health Check
- Can I use oat-sa/bundle-health-check in a Laravel application?
- Not directly. This package is a Symfony bundle: it registers services, a DI extension and compiler passes through a Symfony Bundle subclass and the Symfony kernel, so it will not boot inside Laravel's service container on its own. Making it work under Laravel would require a bespoke bridge that your team owns and maintains. For a diagnostics bundle that is rarely worth the effort, so treat "drop-in for our Laravel estate" as unvalidated until a supported integration path is confirmed.
- How do I install and register oat-sa/bundle-health-check?
- Install it with Composer, for example composer require oat-sa/bundle-health-check (add --dev if you only need it for pipelines and local diagnostics). Then register the bundle in your Symfony kernel or config/bundles.php and let the bundle's DI extension wire its services. Because 2.3.3 widens framework support, pin an explicit constraint such as ^2.3.3 and rely on your lockfile rather than floating versions.
- Which Symfony versions does oat-sa/bundle-health-check 2.3.3 support?
- Release 2.3.3 is described as adding Symfony 7.4 compatibility, which almost certainly means a widened composer.json constraint rather than new runtime logic. Widened constraints can permit combinations the maintainers never tested, such as 7.4 alongside older adjacent Symfony components. Diff composer.json between 2.3.2 and 2.3.3 before pinning, and confirm the maintainer's stated support matrix and end-of-life policy directly.
- What does this bundle actually do at runtime?
- It provides configurable health and readiness checks for PHP applications, exposed as diagnostic endpoints that verify dependencies and service availability. The reported status is aimed at monitoring systems, load balancers and orchestration tools so operators can detect failures early. In practice that makes it an ops and diagnostics utility rather than request-serving application code, which keeps its potential blast radius low.
- Should oat-sa/bundle-health-check be a require-dev dependency or a production dependency?
- That is one of the open questions and it depends on whether the checks are meant to run in production environments or only in CI and local development. The safe starting point for a first adoption is require-dev, installed and validated in a single non-critical pipeline. Only promote it to production once a concrete operational need for live health endpoints is demonstrated.
- Is oat-sa/bundle-health-check actively maintained?
- Stewardship is the dominant unresolved risk. The 2.3.3 release shows a first-time contributor plus a single maintainer handling the framework bump, and bus factor and release cadence are not evident from the repository alone. The project sits within the TAO / oat-sa ecosystem, which makes continued Symfony support plausible but not guaranteed. Run vendor diligence and ask about a 2.3.x support commitment before standardising on it.
- Does version 2.3.3 introduce breaking changes for existing users?
- No. It is a patch release on the 2.3.x line, which implies a stable API, and the two changes are a CI hygiene fix plus Symfony 7.4 compatibility. The CI change replaced a hardcoded SONAR_HOST_URL with a secret reference, which is a pipeline process concern rather than shipped runtime behaviour. Verify the composer.json diff yourself, then a standard lockfile update is enough.
- How do I check whether I already depend on this bundle transitively?
- Run composer why oat-sa/bundle-health-check in each project and inspect the dependency tree. This matters in TAO or QTI-based tooling, where the bundle may already be pulled in without anyone explicitly requiring it. If it is only a transitive dependency, pinning the top-level constraint is usually preferable to adopting it directly.
- What are the alternatives to oat-sa/bundle-health-check for Laravel projects?
- Laravel ships a built-in health endpoint at /up, and packages such as Spatie's Laravel Health add configurable checks for databases, queues, caches and disks. Those are first-class Laravel integrations and require no Symfony container bridge. If your runtime is genuinely Symfony 7.x, this bundle is idiomatic and a reasonable choice instead.
- How do I safely roll out and test the health checks in a pipeline?
- Because this is a diagnostics layer, worst-case failure is a red CI job rather than a production outage. Start by installing it in a single non-critical pipeline, hit the health and readiness endpoints and assert on the returned status codes. Audit the transitive footprint too, since health-check bundles often pull in HTTP clients or profiler integrations. Expand adoption only after that pipeline has stayed green.
Weaver
How can I help you explore Laravel packages today?