- Is kiora/health-check-bundle a Laravel package?
- No. Despite being installable via Composer, this is a Symfony bundle, confirmed by the -bundle suffix, the repository contents, and Symfony-idiomatic conventions. It ships no Laravel service provider, facade, or publishable config/health-check.php. For a Laravel-only estate it is a conceptual mismatch rather than a drop-in dependency.
- Can I install kiora/health-check-bundle in a Laravel app with Composer?
- Composer will resolve and install it, and the MIT license removes any legal friction. What you do not get is Laravel auto-discovery, route registration, or a config file to publish. Expect to write glue code before the package does anything useful in a Laravel application.
- What endpoints does this health check bundle expose?
- Version 1.1.0 provides a lightweight /ping liveness endpoint and a /ready readiness endpoint aimed at Kubernetes probes. These are the two endpoints a platform team would otherwise hand-roll. Health check groups imply checks can be partitioned across them, though you should confirm group assignment in the source.
- What kinds of health checks can I register?
- The package supports pluggable checks for databases, caches, and custom services, with structured per-check status and timing output. v1.1.0 adds health check groups, multiple database connection support, performance statistics, and caching. The scope grew substantially in one release, so pin the version you validate.
- How would I integrate this bundle into a Laravel application?
- You would need a service provider, route registration, and a config loader to bridge Symfony bundle conventions into Laravel. That is adaptation, not adoption, and the effort is unchanged by v1.1.0. The cleaner contract (/ping, /ready, groups) gives you a better-specified target, but portability is still unconfirmed in the release notes.
- Does it return JSON and what HTTP status codes does it use?
- It returns structured JSON with per-check status and timing, and maps health state to HTTP status codes for healthy and unhealthy probes. Performance statistics in v1.1.0 imply a richer payload. The exact JSON schema and the semantics for partial failure, degraded versus down, are still undocumented, so verify them in the source before relying on them.
- Is kiora/health-check-bundle production ready and actively maintained?
- It is run deliberately: CI/CD workflows, PHPStan level 9 static analysis, a SECURITY policy, CONTRIBUTING, and a CODE_OF_CONDUCT. Third-party validation is still zero, with one star, no dependents, and no reported production use. Bus factor is one, and every v1.1.0 pull request was authored by the same maintainer.
- How does it compare to Laravel-native health check packages?
- For a Laravel-only estate, Laravel-native packages win on integration cost because they register routes and config for you. This bundle is credible for a mixed PHP estate where one standard health surface across Symfony and other services has real value. Judge it on estate breadth, not on Laravel ergonomics.
- Can I use it for Kubernetes liveness and readiness probes?
- Yes, that is the design intent: /ping for liveness and /ready for readiness, with load balancers and uptime monitors as additional consumers. Health check groups suggest you can split cheap liveness checks from dependency-heavy readiness checks. Confirm in source how a check is assigned to a group before wiring probes.
- Are per-check timeouts enforced, and is it safe to run in production?
- Per-check timeout enforcement is still unanswered by the maintainer, so test it explicitly. Blast radius is contained: the endpoints are read-only and non-transactional, so a failed integration degrades observability rather than the application. Given the single-maintainer risk and rapid surface-area growth, run a time-boxed spike and pin the version you validate.