Actuator Doctrine Bundle Laravel Package

Product Decisions This Supports

• Feature scope for service health checks. The bundle adds a Doctrine (database) connection health indicator to symsensor/actuator-bundle's health endpoint. That directly informs a concrete product feature: "does this service report dependency status, not just process liveness?"
• Readiness vs. liveness semantics. A key decision this enables is whether a DB outage should trigger a container restart (liveness) or simply pull the instance out of the load balancer (readiness). This package feeds the readiness side, which is the correct design — it supports the argument that database failure should degrade traffic routing, not cause restart loops.
• Framework-version gate (new in v1.1.0). The v1.1.0 release implements Symfony 7.0 compatibility. This removes the previous hard blocker for teams standardizing on Symfony 7.x / 6.4 LTS and turns "can we use this at all?" into "do we want to?" — which is the right question to be asking anyway. It also means the package's Composer constraints moved; teams on Symfony 5/6 should confirm their version is still satisfiable before assuming a drop-in upgrade.
• Build vs. buy for observability glue. The capability is small and well-bounded (a health indicator plus config). The real decision is whether to adopt a low-adoption dependency, fork it internally, or write ~50–150 lines against Doctrine's Connection object. This package is the "buy" option, and the assessment remains that "build/fork" is likely cheaper than owning a lightly-maintained dependency.
• Roadmap input for an observability/platform epic. If the roadmap includes standardized health endpoints across Symfony services, this is one candidate building block in the dependency-health layer, alongside cache, queue, and HTTP-dependency probes.
• Incident response and MTTR. Exposing DB reachability in a standard health payload shortens on-call triage ("is it us or the database?") and supports SLO work on DB-dependent user journeys.
• Deploy safety. During rolling deploys, readiness gating on DB connectivity prevents routing traffic to instances that cannot serve requests — a decision worth formalizing in the deployment runbook.
• Dependency governance / procurement. Adopting this still forces an explicit decision on accepting a low-community transitive dependency (0 stars, no known dependents, a single compatibility release after a ~2-year gap). v1.1.0 is a positive signal of life, not evidence of a maintenance commitment. That decision should be made deliberately, not by accident via composer require.

When to Consider This Package

Consider it when all of the following hold:

• The service is Symfony (this is a Symfony bundle, not a Laravel package — it will not work in a Laravel/Eloquent app at all, which is the first scoping filter). v1.1.0 adds Symfony 7.0 support, so Symfony 7 apps are now in scope where previously they were not.
• The service uses Doctrine ORM/DBAL for its data access.
• symsensor/actuator-bundle is already in use — this is strictly an add-on and has no standalone value.
• You are containerized (Kubernetes, ECS, etc.) and want dependency-aware readiness probes without building a custom health subsystem.
• The team is small enough that a ready-made indicator saves meaningful time, and the platform team is comfortable pinning and reviewing third-party code.

Look elsewhere (or fork) when:

• You are on Laravel or another non-Symfony framework — out of scope entirely.
• You are on a Symfony version the new release does not cover (e.g. an older branch if constraints were raised) and cannot upgrade — verify composer why-not before planning around it.
• You need query-level performance data (slow query logs, statement timing) — that is the Doctrine profiler, Symfony's profiler, or Blackfire/Tideways, not a health indicator.
• You need Prometheus/OpenTelemetry metrics rather than a boolean health endpoint — use a dedicated exporter or OTel instrumentation.
• Your organization requires maintained dependencies, security response commitments, or vendor support. One Symfony 7 compatibility commit after a two-year quiet period is a maintenance signal, not a guarantee; treat this as a reference implementation rather than a supported library.
• The health requirement is simple enough that a small in-house indicator (a SELECT 1 against the connection behind a Symfony health check) is both cheaper to own and easier to test. At this scope, the package's main value is as a pattern to copy.

Practical guidance: evaluate symsensor/actuator-bundle first — it is the actual platform decision. This package remains a low-risk optional extra whose correct treatment is "fork it, pin it, or replicate it," not "depend on it." v1.1.0 is a non-breaking minor bump (1.0.2 → 1.1.0), so it does not force a re-evaluation of existing plans; it only widens the addressable Symfony versions.

How to Pitch It (Stakeholders)

For executives. This is a small, free, MIT-licensed add-on that makes a Symfony service's health endpoint also report whether its database connection is healthy. That matters for two reasons: it improves deploy safety (traffic is not routed to instances that cannot reach the database) and it cuts incident triage time (on-call can distinguish "service broken" from "database unreachable" in seconds). The newly published v1.1.0 adds Symfony 7 compatibility, which clears the main technical objection we had — the package can now run on our current framework line. The cost is near zero; the residual risk is that the project has very little adoption and this is its first release in roughly two years, so it should be treated as a pattern to adopt, not a supplier to rely on. Recommendation: a one-day spike, then either fork it internally or replicate the check in-house. Do not add it to a production critical path as-is.

For engineering. It is a thin Symfony bundle providing a Doctrine connection health indicator for the actuator bundle's health endpoint. v1.1.0 is a compatibility-only release — Symfony 7.0 support, no new features, no deprecations announced, and a minor version bump implying no breaking changes; existing Symfony 5/6 users should still verify Composer constraints before upgrading. Effort to replicate is small (one health indicator class plus a config block), and replicating gives us our own tests, error handling, timeout behavior, and a maintained dependency graph. Recommendation: spike it in a non-production service, read the source (it is short), and if the shape fits, vendor or fork it with a pinned version and a smoke test. If we skip it, log the requirement in the platform backlog so the gap in DB-dependency health coverage is tracked rather than forgotten.