Product Decisions This Supports
- Observability investment sizing. Statamic Vitals gives us a built-in, zero-config health snapshot inside the control panel (PHP version, environment, cache, storage, queue status). That answers a real question before we spend anything: is a dedicated APM/observability contract worth the money for this CMS estate, or is a lightweight CP widget enough for day-to-day operations? Treat the widget as a cheap experiment before committing observability budget.
- Build vs. buy on internal tooling. The alternative is a custom "site health" page in the CP — a small but permanent piece of internal code that has to be maintained across every Statamic major. This package is MIT, zero-config, and extensible via custom checks. For a diagnostics panel of this scope, adopting is almost always cheaper than owning. Only build in-house if we need checks it can't express or need to control the data path.
- Roadmap sequencing against Statamic v6. v1.3.0 is a compatibility release ("Add support for Statamic v6"). It removes a blocker for the Statamic v6 / Laravel upgrade: pin
^1.3.0 on the upgrade branch and treat anything below it as a likely upgrade impediment. This is a gating input to the platform upgrade plan, not a feature input.
- Launch and handoff readiness. A pass/warn/fail dashboard is directly usable as a pre-launch checklist artifact and as an agency-to-client handoff tool — "here's how you confirm the site is healthy." It supports process decisions (do we require a health check before go-live?) more than product decisions.
- Incident triage workflow. When an editor reports "the site is broken," a CP-visible status panel shortens the loop between symptom and cause (cache, storage permissions, queue backlog). It supports a decision about where first-line triage lives — with editors/account managers, or with engineering.
- Not supported by this package: historical metrics, alerting, SLIs/SLOs, or trend analysis. It is a point-in-time snapshot. Do not let its presence substitute for an incident response or monitoring strategy decision.
When to Consider This Package
Consider it when:
- We run Statamic and want basic health visibility without standing up new infrastructure — no agent, no external service, no new runtime.
- The team is small or lacks dedicated DevOps, and "is the site healthy?" currently gets answered by SSH-ing in or asking an engineer.
- We want a low-cost, low-blast-radius diagnostics layer for pre-launch checks, agency handoffs, or a multi-site estate where "which site has a problem" is a recurring question.
- We are planning the Statamic v6 upgrade — v1.3.0 is the minimum viable pin for that path.
- We anticipate needing custom checks specific to our stack (third-party API reachability, license expiry, custom queue names) — the extensible-check architecture is the main reason to prefer this over a bespoke panel.
Look elsewhere or defer when:
- We already have mature external observability (APM, uptime monitoring, error tracking, log aggregation). This package duplicates a fraction of that with none of the history or alerting, and adds a dependency for marginal value.
- We need alerting, historical trends, or SLO reporting. It provides none of these, and it will not grow into them — that's a different product category.
- The requirement is vendor-supported, compliance-grade monitoring. A 5-star, single-maintainer package is not that, regardless of quality.
- We are not on Statamic. Nothing here transfers.
- The package would sit on a critical operational path (e.g. the only way we detect outages). Bus factor and support commitments don't justify that role.
Before adoption, verify (not answerable from the description): actual check coverage versus what we care about, behavior on a failing check (does it degrade gracefully or break the CP?), whether the widget is CP-only or exposes an external endpoint (the description says "for external usage" — clarify what that means), and the maintainer's activity and issue responsiveness. Star count is 5, so assume small-install-base risk and validate on a pilot site first.
How to Pitch It (Stakeholders)
For executives — one paragraph: Statamic Vitals is a free, open-source add-on that puts a health dashboard inside our CMS admin. It shows, at a glance, whether the site's runtime, cache, storage, and queues are in a healthy state — the kind of check that currently requires an engineer to investigate. The business case is time-to-diagnosis and reduced dependence on engineering for basic questions, not new revenue or customer-facing capability. Cost is near zero (MIT license, no infrastructure, no vendor contract), risk is low because it is read-only diagnostics, and it also happens to unblock our planned Statamic version upgrade. The caveat: it is a small, community-maintained project, so we should treat it as a convenience layer, not as our monitoring system of record, and we should not put it on a critical operational path.
For engineering — the ask: Install on one non-production site first. Confirm what each check actually tests, confirm behavior when a check fails (the CP must degrade gracefully, not break), and confirm what "external usage" means in practice. Then pin ^1.3.0 — that's the version with Statamic v6 support — and treat anything lower as an upgrade blocker. Budget roughly a day for the pilot plus an hour of custom-check work if we want our own checks. Explicitly agree that this supplements our monitoring stack rather than replacing it, and that if we later want alerting or history, that's a separate decision.
The honest caveat to state upfront: this is a 5-star, likely single-maintainer package. Its value is convenience, so if the maintainer goes quiet, the correct response is to remove it or vendor it — not to panic. We should also be clear that the release note for v1.3.0 tells us nothing about feature completeness; it's a compatibility line. Approve it as a cheap, reversible operational improvement, not as a strategic platform bet.