Statamic Healthchecks Laravel Package

Product Decisions This Supports

• Production readiness / launch gates: Statamic is a flat-file CMS, so the usual "is the database up?" check tells you almost nothing. A dedicated health-check endpoint gives you a concrete, automatable signal for go/no-go decisions on launches, migrations, and infrastructure changes.
• Uptime monitoring buy vs. build: Rather than building custom /up-style controllers and bespoke check logic per project, adopt the package and point your existing monitor (UptimeRobot, Oh Dear, Better Stack, Pingdom, or an internal Prometheus blackbox exporter) at the endpoint. The decision becomes "which monitor do we pay for," not "how do we instrument the app."
• Support-matrix and platform roadmap: 1.1.0 adds Statamic 6 support alongside the existing 1.0.0 line. This directly unblocks the Statamic 5 → 6 upgrade on the roadmap, because the monitoring layer no longer becomes a blocker or a fork-and-patch chore.
• Standardization across a portfolio: If you run multiple Statamic sites (agency, multi-brand, multi-tenant), one consistent health endpoint across all of them simplifies runbooks, alert routing, and on-call handover.
• Incident response scoping: A structured health payload shortens the "is it us or is it the host/CDN/cache?" triage step, which is a measurable MTTR input.
• Prioritization signal: The maintainer shipping a Statamic 6 compatibility release promptly is evidence of active maintenance — a factor in whether to standardize on this package versus pinning an internal implementation.

When to Consider This Package

Adopt it when most of the following are true:

• You run Statamic (now on 5.x or 6.x) in production and have — or want — an external uptime monitor.
• You have no health endpoint today, or you have ad-hoc ones that differ per project.
• You want the monitoring layer to survive Statamic major upgrades without becoming a maintenance item; 1.1.0's explicit Statamic 6 support is the relevant proof point.
• Your team is small enough that a thin, single-purpose, community-maintained package beats an in-house module you'd have to own and test against every Statamic release.
• You need an HTTP-addressable check consumable by third-party monitors, not a deep APM/tracing story.

Look elsewhere when:

• You need deep observability — traces, per-query latency, queue depth dashboards. Reach for Laravel Telescope, Nightwatch, Sentry, or a full APM instead; a health-check package is a binary/alarm signal, not an observability platform.
• You need fine-grained, custom check authoring (disk thresholds, third-party API probes, business-KPI assertions) as a first-class feature. Spatie's laravel-health or Laravel's built-in health routing is a better fit for a broad, extensible check catalogue.
• Your stack is not Statamic — the value here is the Statamic-specific integration, and a generic Laravel health package would be the correct dependency.
• You require vendor-backed SLAs or long-term commercial support; this is a small, single-maintainer community package.
• You're on a Statamic version older than what 1.x targets — verify compatibility before committing, since the release notes only explicitly call out Statamic 6.

Pre-adoption diligence for 1.1.0: confirm the actual version constraint now declared (does 1.1.0 widen to ^5|^6 or move to 6 only?), confirm whether 1.0.0 users on Statamic 5 are expected to stay put, and check that the endpoint is safe to expose publicly (auth/obfuscation, no secrets or version numbers in the response body).

How to Pitch It (Stakeholders)

For executives — one paragraph: We're standardizing production monitoring for our Statamic sites on a small, focused package that exposes a health-check endpoint our existing uptime monitor can poll. It replaces per-project custom code with one dependency, and the newest release (1.1.0) adds Statamic 6 support — which removes a blocker from our planned CMS upgrade. Cost is negligible, the change is low-risk and reversible, and the benefit is faster detection of outages and a smoother major-version upgrade.

For engineering — the substance: govigilant/statamic-healthchecks 1.1.0 adds Statamic 6 compatibility. This is a compatibility release, not a feature release: no new capabilities, no stated breaking changes, no deprecations announced. Practical impact is that the package stays viable through our Statamic 5 → 6 migration instead of forcing us to pin, fork, or replace it mid-upgrade. Before we adopt: (1) verify the new composer.json constraint — whether it's additive (^5|^6) or a hard move to 6 — since that determines whether Statamic 5 sites can share the same pinned version; (2) review what the endpoint actually reports and confirm nothing sensitive is exposed if it's publicly reachable; (3) wire it into our existing monitor and alert routing rather than standing up new tooling.

Recommendation: Approve for a pilot on one production Statamic site (or a staging site first, then production), with a short verification of the version constraint and endpoint exposure before rollout. Success criteria: monitor shows green, an induced failure flips it red within the expected interval, and the Statamic 6 upgrade path is validated end-to-end. Roll to the rest of the portfolio if the pilot is clean.

Caveat to flag: this assessment is based solely on the 1.1.0 release notes, which are a single line. The compatibility claim should be confirmed against the package's repository and changelog before it's treated as validated for the upgrade plan.