Nova Health Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. This reframes the question from "should we build a health screen?" to "do we add a small MIT-licensed widget to an admin surface we already license and use daily?" For Nova shops, it is a legitimate try-before-you-build option — but only for in-app readiness visibility, not monitoring.
• Whether operational health belongs in the admin panel at all. The real product question isn't "is this package good," it's "should ops and support see health signals in the same screen where they handle customer workflows?" A reversible trial is the cheapest possible way to test that thesis. If the answer is no, you've spent almost nothing to learn it.
• Pilot scoping and investment level. 13 stars, zero dependents, one maintainer, last release February 2025. That profile mandates a time-boxed spike with named success metrics (reduced triage time, fewer ad hoc php artisan checks, faster post-deploy confidence) — never a standardization or platform decision.
• Roadmap deferral on observability. Adoption can defer one cycle of alerting, historical metrics, or SLO tooling while you gather evidence on whether in-panel health checks actually change operator behavior. It buys time and evidence; it does not substitute for that investment.
• Release-readiness workflow design. Forces the decision of whether post-deploy verification lives in Nova (visible to non-engineers, non-blocking) or in CI (automated, gates a bad release). Useful signal about whether the org values visibility or enforcement.
• Supplier and maintenance risk posture. Zero dependents and a single maintainer are not evidence of production hardening. This is a deliberate, recordable risk-acceptance decision for internal-only tooling — write it down rather than let it become an implicit default.
• Authorization and information-disclosure policy. Health output routinely leaks DSN shapes, disk paths, queue depths, and service reachability. Adoption forces an explicit decision about which role sees operational internals in a shared admin panel.

When to Consider This Package

Adopt when:

• Nova is already licensed and load-bearing. The entire value is delivery through Nova's UI. Nova's per-site license is part of the real cost — if Nova isn't already paid for and used daily by ops/support, the economics invert and you'd effectively be buying an admin panel to host a health widget.
• You need coarse, human-readable status, not observability. Database, cache, queue, and storage checks answer "is the app basically okay right now." That's triage convenience, not monitoring.
• The dashboard can be gated to an ops role. Confirm the default canSee / authorization behavior in source before production; community tools often default to "any authenticated Nova user." Ship the gate in the same PR as the install.
• Multi-node deployments are paired with an external prober. Health is a per-process property — behind a load balancer the panel truthfully reports whichever node served the request. Keep real uptime checks external and treat this as one sample.
• You want a reversible experiment. No migrations, no data model, additive registration. Removing it is composer remove plus one line from NovaServiceProvider. Reversibility — not the feature set — is the main reason to trial rather than build.

Look elsewhere when:

• You need alerting, history, SLOs, or fleet-wide status. Use Laravel Pulse, Sentry, a managed uptime service, or platform-native monitoring. This package will not page anyone and has no trend data.
• You need vendor support or a compatibility guarantee. Single maintainer, low-traffic issue tracker, unproven Nova major-version matrix. Pin the exact version and read the declared Laravel/Nova constraints in composer.json before committing.
• Nova isn't strategic. If the team is migrating off Nova or non-Nova users need health visibility, a standalone integration is the better bet.
• You cannot verify authorization defaults or read the check implementations. A timeout that silently reports "pass" converts "we don't know" into "we checked and it's fine" — worse than no dashboard. Unknown behavior here is a blocker, not a caveat.
• You intend to wire it into a deploy gate. Nova Health is for humans triaging; it doesn't block a bad release and a flaky check must never block a rollback. Keep smoke checks in CI.

How to Pitch It (Stakeholders)

To executives: "This is a small MIT-licensed add-on for the Laravel Nova admin panel we already pay for. It would show basic application health — database, cache, queue, storage — on one screen for the ops team. It's cheap to trial and completely reversible: no database changes, and removal is a two-line cleanup. Adoption is very low (13 stars, no downstream users, one maintainer), so I'm recommending a time-boxed internal pilot with a written success metric, not a platform standard. It is explicitly not a replacement for our monitoring and alerting, and it carries a documented single-maintainer risk that we're accepting for internal tooling only."

To engineering: "If we're staying on Nova, this may save us building a simple health screen. Before we install I need four answers from the source, not the README: which Laravel and Nova majors are declared compatible; whether checks are self-contained or wrap spatie/laravel-health or our /up route; what the default authorization behavior is and how we gate it; and whether checks run synchronously on page load or are cached. Anything network-bound gets cached or replaced before production. We position it as a second surface over checks we already have — the alerting path stays where it is. Fallback is a fork (MIT makes that trivial) or deletion, since nothing depends on it."

To support and ops: "The upside is one screen in the tool you already use for customer workflows, instead of asking an engineer to run commands. The caveats matter: it samples one server, not the fleet, so during a partial outage you can see green while customers see red. It does not alert — the monitoring system remains the source of truth for anything that pages someone. If the screen goes blank, that usually means Nova is down, not necessarily the app."

PM recommendation: Treat it as an evaluation candidate for in-panel operational visibility — gated to an ops role, trialed in a non-critical Nova environment for one cycle. Define the success metric up front (triage time, fewer ad hoc checks, or faster post-deploy confidence), name an owner who accepts Nova-upgrade maintenance, and document the fork-or-drop procedure now while it's still a thought experiment. Expand only if the pilot hits its metric; if maintenance stalls, invoke the documented decision rather than letting the pilot drift into a default.