Statamic Vitals Laravel Package

Technical Evaluation

Architecture fit marcorieser/statamic-vitals is a Statamic addon: a Composer-installed Laravel package that registers a control-panel widget, ships publishable config, and runs a registry of configurable health checks (PHP version, environment, cache, storage, queues). Architecturally it is additive and read-only — it observes runtime state, it does not own content models, routes, or the data layer. That is the ideal shape for a TPM to sponsor: the blast radius of a failure is "the dashboard is wrong or missing," not "the site is down." It also requires no new runtime (no Node service, no external daemon, no database tables), so it adds zero infrastructure surface and zero procurement.

The one architectural detail that matters for us is the description line "provide vitals of your Statamic installation for external usage." If that means an HTTP endpoint or CLI export beyond the CP widget, it is a security-relevant surface, not just a UI convenience — it must be confirmed as authenticated, permission-gated, and non-disclosing (no env values, no paths, no credentials) before it goes anywhere near production.

Integration feasibility Low effort, standard Composer consumption: require the package, publish config, register/enable the widget, clear caches. Realistic estimate is well under a sprint for a single site, most of which is deciding which checks matter to us rather than installing anything. Feasibility risk is not installation — it is version coexistence. v1.3.0's changelog is a single line ("Add support for Statamic v6"), which does not tell us whether the constraint widened (v5 and v6 both supported) or narrowed (v6 only, v5 users frozen at v1.2.x).

Technical risk

• Low-to-medium overall, but concentrated in two places. First, dependency health: 5 stars, single maintainer, and an opportunity score of 1.19 indicate very low adoption. We would be one of a handful of consumers, which means we are effectively co-maintainers of our own risk.
• False confidence is the real product risk. A green dashboard that is not actually checking the thing we care about is worse than no dashboard, because it suppresses the investigation that would otherwise happen. If the built-in checks do not cover our actual failure history (queue backlog, scheduled-task heartbeat, disk headroom, cache reachability, search index drift), the widget is decoration.
• One-line disclosure on a major-version-support release is thin. Statamic majors historically move internals; "v6 support" may have required real internal changes whose consumer-visible effects (renamed config keys, republished assets, changed check signatures) are undocumented.
• Version-coupled to Statamic's cadence: every future Statamic major becomes a dependency review for us.
• Privilege and disclosure: health checks touch storage, cache, and queue configuration. Confirm the widget is CP-auth-gated and that any external-facing surface is off by default.

Key questions

1. Did v1.3.0 widen the constraint to allow Statamic v5 and v6, or replace v5 support? What is the composer.json diff between v1.2.x and v1.3.0?
2. What are the new minimum PHP / Laravel / Statamic versions, and do those floors force an unrelated platform upgrade?
3. Is there a maintained v5 branch, and what is its support window?
4. Is there any network-reachable surface ("external usage")? If so, how is it authenticated and what exactly does it expose?
5. What is the full built-in check list, and can we author custom checks against our own SLOs (queue depth, cron heartbeat, disk, dependency reachability)?
6. Are results pull-only (someone must look at the CP) or can they push to our alerting? Pull-only changes the operational value proposition substantially.
7. Are checks executed on every CP page load, or cached/scheduled? This determines whether it is free or a small per-request tax.
8. Does CI actually exercise the v6 path?

Integration Approach

Stack fit Excellent on paper. Pure PHP addon on Laravel + Statamic, consuming the container, config, cache, and queue primitives we already run. No new language, no new deploy artifact, no new on-call surface. It fits inside our existing Composer/CI tooling and our existing PHP support policy — the only policy interaction is the transitive PHP/Laravel floor.

Migration path

• Pin explicitly. Resolve to ^1.3.0 only on sites on (or moving to) Statamic v6; hold everything else on an explicit last-known-good v1.2.x constraint rather than floating.
• Sequence outward-in: confirm the target PHP/Laravel/Statamic baseline is satisfiable → upgrade Statamic core → upgrade this package → re-publish assets and clear caches (Stache, view, config) → open the CP and verify each check renders and behaves.
• Install on staging first with the widget visible only to engineering, tune the check set to what we actually page on, then promote.
• If we are not on a Statamic v6 timeline, treat this as a no-op: v1.3.0 buys us nothing on v5 and delivers no new capability. Do not manufacture an upgrade project around a compatibility release.

Compatibility Maintain an explicit matrix — package version × Statamic version × Laravel version × PHP version — derived from composer.json and CI, not from release notes. Assume v1.3.0 is unvalidated against Statamic v4 and earlier, and assume v1.2.x is frozen at whatever it shipped with. Enforce lockfile review in CI so a constraint collision surfaces as a build failure rather than a silent resolve to an older version.

Sequencing

1. Read the composer.json diff (constraint change is the single most informative artifact).
2. Answer the external-surface question before any production install.
3. Pilot on one non-critical site with a deliberately small, meaningful check set.
4. Wire the widget into the on-call runbook — who looks at it, when, and what action each red state triggers.
5. Only then add it to the standard site template and schedule it into the fleet build.

Operational Impact

Maintenance Steady-state cost is genuinely low — one Composer line, no schema, no infra — provided the package stays alive. The real cost is the compatibility matrix we now own and the fact that this dependency inherits Statamic's release cadence. Budget a small recurring allowance per Statamic major, not a standing project. If the maintainer goes quiet, the fallback is a fork or a reimplementation; both are cheap here because the surface is small, which is precisely why this is a tolerable risk rather than a strategic one.

Support This is where the TPM value actually lands: it converts "the site feels slow / editors can't save / is the queue running?" escalations into a self-serve CP view. That is a measurable reduction in tier-1 noise, but only if two things are true — the check set maps to our real incident history, and someone owns the interpretation. Without an owner, every red indicator becomes a new support ticket with no routing. Publish a one-page internal note: what each check means, the threshold, the first action, and the escalation path. That document, not the package, is the deliverable.

Scaling Neutral. Checks read existing Laravel state; they do not add workers, storage, or a data model. The only scaling question is execution cost if checks run on every CP request — verify and, if needed, accept or cache. This is a sanity check on the pilot, not a capacity project.

Failure modes

• False green (worst case). The dashboard says healthy while the thing that actually breaks us goes unmonitored. Mitigation: define our required checks first, then verify the package covers them; add custom checks for gaps.
• Alarm fatigue. Too many warn states nobody acts on trains the team to ignore the widget entirely. Mitigation: trim to checks we would actually page on.
• Disclosure via external surface. If an unauthenticated vitals endpoint exists or is misconfigured, we leak environment and infrastructure detail. Mitigation: confirm and, if necessary, disable before production.
• Silent breakage on upgrade. Widget fails or renders stale after a Statamic bump, and because it is "just a dashboard" nobody notices it stopped working. Mitigation: include a CP smoke test in the upgrade runbook.
• Constraint collision / PHP floor breach. Site on v5 resolves down to an old package version, or the package's Laravel floor drags unrelated dependencies. Surfaces loudly in CI — the good failure mode.
• Abandonment. Package goes stale, we carry a dashboard we cannot upgrade. Low cost to absorb, but record it as accepted risk rather than discovering it during a crisis.

Ramp-up Very low. Any Laravel-fluent engineer can install and configure this in an afternoon; the knowledge that actually gates value is Statamic addon anatomy (CP asset publishing, Stache/cache clearing) plus incident history — knowing which signals matter. Assign one engineer to run the pilot and author the internal runbook note. That artifact, together with a short Statamic v6 validation spike, is the whole of the ask — and it is the difference between a decorative widget and a durable reduction in escalations.