- How do I install gavtaylor/laravel-health-route in a Laravel application?
- Install it with composer require gavtaylor/laravel-health-route, then optionally publish the package config if you need to customise checks, route settings, or access control. The service provider registers the health route and view layer, so integration is typically a sub-day task for an existing Laravel app. Pin the version you adopt, especially while the package is pre-1.0.
- Does this package replace Laravel's built-in health route?
- gavtaylor/laravel-health-route is positioned as a drop-in replacement for Laravel's built-in health route, adding a customisable HTML view, a richer JSON contract, opt-in structured checks, and composable access control. It is more useful than a hand-rolled /health closure when you need both a human-friendly dashboard and a strict machine-readable probe from the same check definitions. Confirm the route name and registration behaviour in the published config before removing any existing health endpoint.
- Which Laravel and PHP versions does this package support?
- The provided overview does not pin an exact support matrix, so check the package composer.json and README before installing. The technical evaluation flags Laravel 11/12 and PHP 8.2+ as the matrix to confirm. Treat version compatibility as a release-review item rather than assuming it matches your app.
- Is EnvironmentCheck safe to expose on a public health route?
- Environment checks can disclose app environment, debug flags, PHP version, or config values, which becomes an information-disclosure risk if the route is publicly reachable. The evaluation flags this as the most important thing to verify before rollout, including whether EnvironmentCheck is gated behind a config flag that defaults to off. Put the route behind auth, an IP allowlist, or equivalent access control if any environment data is exposed.
- How does the package return HTML versus JSON, and do they order checks differently?
- Both renderers are driven by the same check definitions, which lets you serve a browser-friendly HTML dashboard and a strict JSON probe without duplicating configuration. The exact negotiation mechanism (Accept header, query parameter, or separate route) should be confirmed in the package config or docs, and JSON should be forceable deterministically for machines. Note that the HTML view sorts checks alphabetically while JSON preserves configured order, an intentional asymmetry to document for on-call staff.
- Are StorageWritableCheck, LogWritableCheck, and EnvironmentCheck enabled by default?
- The v0.2.0 release adds these three bundled checks, but the evaluation expects them to be opt-in via configuration to keep the default payload lean. Confirm the defaults in the published config rather than assuming. If you enable them, review the resulting JSON contract and any information disclosure implications.
- Do the storage and log writability checks cause disk I/O on every probe?
- Yes. StorageWritableCheck and LogWritableCheck perform filesystem writes each time the health route is invoked, so aggressive Kubernetes probe intervals can create continuous disk I/O and log noise across replicas. Check whether results are cached with a TTL to bound that cost, and consider longer probe intervals or disabling write checks in high-frequency liveness probes. Keep readiness checks separate from liveness checks where possible.
- What happens if LogWritableCheck cannot write to the log target?
- The evaluation raises a self-referential failure mode: if the check writes to the log channel to prove writability, a failing log target may produce errors the check itself cannot report. Confirm whether it probes the handler directly or emits a test record. Also check whether checks can be weighted so a degradable check can warn without failing the whole endpoint and triggering a restart loop.
- What HTTP status does the health route return when a check fails?
- The provided overview does not specify whether failures return 503 or 200 with a failure body, but load balancers and Kubernetes probes depend on that behaviour. Verify the status-code contract in the package config or docs before wiring the route to infrastructure. For most load-balancer probes you want a non-2xx status on failure so unhealthy instances are removed.
- Is gavtaylor/laravel-health-route production-ready at version 0.2.0?
- It is pre-1.0, so there is no compatibility guarantee for config keys, check interfaces, or route naming. The v0.2.0 release itself is additive and low-risk, adding three checks and HTML presentation refinements without removing or renaming anything. Pin to ~0.2.0, treat upgrades as reviewed changes, and confirm maintainer cadence and licence before relying on it in production.