- Is ongr/monitoring-bundle a Laravel package?
- No. It is a Symfony bundle built around Bundle registration, a DI Extension loading services.yml, tag-based check discovery, and a shipped routing file imported under a prefix such as /_monitor. Laravel has no equivalent bundle pipeline, so the packaging is non-transferable. Only the small core (a check interface, an aggregator, and a controller returning 200/503) is worth copying.
- How do I install ongr/monitoring-bundle with Composer?
- In a Symfony application you run composer require ongr/monitoring-bundle, register the bundle in your kernel or bundles.php, and import the bundle routing with a prefix. In Laravel you should treat Composer installation as off the table, because the old Symfony and PHP constraints will collide with a Laravel 10 or 11 dependency graph. Read the source and reimplement the pattern natively instead.
- Which PHP and Symfony versions does ongr/monitoring-bundle support?
- It is a Symfony 2 and 3 era package, so expect a composer.json pinned to PHP 7.x and legacy symfony/* constraints. Forcing it into a PHP 8.2+ Laravel 10 or 11 install would require --ignore-platform-reqs or constraint relaxation, which is how dependency debt starts. Check the last commit date and the declared ranges before relying on it anywhere.
- How do I build a Laravel health check equivalent to ONGR Monitoring Bundle?
- Define a HealthCheck contract returning a status and message, register one implementation per dependency, aggregate the results in a service, and expose a single Route::get('/health') that returns 200 when all checks pass and 503 otherwise. That is roughly fifty lines you fully own. Laravel 11's built-in /up route plus spatie/laravel-health covers the same ground with zero maintenance burden.
- What endpoints does ongr/monitoring-bundle expose for uptime monitoring?
- It ships a Symfony routing file that is imported under a prefix, typically exposing a single aggregated health endpoint that collapses check results into one HTTP status code. That fits Kubernetes readiness and liveness probes, uptime monitors, and operational dashboards. These are Symfony routes, not Laravel routes, so they cannot simply be imported into a Laravel application.
- Can I add custom health checks to ongr/monitoring-bundle?
- Yes. You implement the bundle's check interface and register your class as a tagged service in Symfony's DI container, which the bundle then discovers. That tag-based discovery is precisely the piece with no Laravel analogue. In a Laravel port you would bind checks in a service provider and resolve them with the container's tagged() helper.
- Does ongr/monitoring-bundle require Elasticsearch or ONGR transport packages?
- That is the first thing to verify in a spike. ONGR is an Elasticsearch-centric organisation, so the bundle may pull ES client or transport bundles into your graph for a check that should be a simple SELECT 1. Inspect composer.json transitives and confirm whether the check contract itself is dependency-free before considering any reuse.
- What does ongr/monitoring-bundle do that Laravel's health route and spatie/laravel-health do not?
- Very little. Laravel 11's /up route handles liveness, spatie/laravel-health handles checks and status codes, Pulse handles application metrics, Horizon covers queue liveness, and Sentry or OpenTelemetry covers the rest. The bundle's only distinct idea is the ergonomic single aggregated endpoint with one class per dependency, which you can reproduce in about fifty lines you control.
- Is ongr/monitoring-bundle maintained and safe to use in production?
- The one star, zero dependents, and low score profile is the signature of an open-sourced internal tool nobody maintained. There is no security response process, no framework compatibility work, and no issue triage, so all of that becomes your responsibility once it is in the dependency tree. Read and reimplement rather than depend on it.
- How should I test a health check aggregator like the one in ongr/monitoring-bundle?
- Test the aggregator's behaviour when a check throws rather than returns unhealthy, and assert the resulting HTTP status code. Cover the 200 and 503 boundary and confirm the response body does not leak internal details. In Laravel, write feature tests that hit the health route with failing and passing check bindings.