Nova Metric Polling Laravel Package

Product Decisions This Supports

• Whether to add live-ish KPI tiles to the internal admin panel. This package lets existing Laravel Nova metric cards (value, trend, partition) re-fetch on a fixed interval instead of only on page load. That directly supports a decision like "should support/ops see queue depth, order volume, error rate, and signup spikes refresh themselves every 30–60s without a manual reload?"
• Build vs. buy for dashboard freshness. The capability is thin — a polling interval on top of Nova's metric endpoint. The real decision is: adopt this MIT extension (hours), vendor/fork it (hours + ongoing ownership), or hand-roll the equivalent in-house (~1–2 dev-days). Framing it this way keeps the team from treating a 7-star package as a strategic dependency.
• Realtime vs. near-realtime architecture. This is the cheap rung on the ladder: no websockets, no Echo/Reverb, no queue workers, no new infrastructure. It's the right call when seconds-to-minutes staleness is acceptable (internal monitoring, launch-day watch, support triage) and the wrong call when it isn't.
• Roadmap sequencing for internal tooling. If the team is already on Nova, this is a low-cost increment that improves stakeholder self-service — PMs and leads stop asking engineering to "pull the numbers" during incidents and launches. If the team is not on Nova, this package is not a reason to adopt Nova.
• Use cases worth scoping: on-call / war-room screens, launch and promotion monitoring, support queue and SLA watch, checkout or signup funnel health, and any dashboard where a stale number causes a wrong decision.

When to Consider This Package

Adopt-worth-evaluating when all of these hold:

• You already run Laravel Nova (paid license) with metrics dashboards in production.
• You need periodic refresh only — staleness of tens of seconds is fine; nobody is watching for sub-second changes.
• The audience is small and internal (ops, support leads, a few PMs), not customers.
• You accept 0 dependents and 7 stars as a signal: you are adopting code you will own. Budget to pin the version, vendor or fork it, and read the source before shipping.
• You've verified Nova and PHP version compatibility — the last release is July 2023, so Nova 4/5 and modern PHP support must be confirmed in staging, not assumed.

Look elsewhere when:

• You need true realtime — use Laravel Echo/Reverb or a websocket-backed dashboard.
• You need history, drilldown, cross-filtering, or alerting — Grafana, Metabase, PostHog, or a proper BI layer; polling a Nova card doesn't give you any of that.
• The dashboard is customer-facing or needs an SLA — don't put an unmaintained single-maintainer package on that path.
• You're on a Nova version newer than the last release supports, or you have a hard rule against low-adoption dependencies. In that case, reimplement the polling behavior in-house; the surface area is small enough that a fork is cheaper than the risk.
• You need polling of non-Nova metrics or a non-Nova frontend — the extension is scoped to Nova's metric cards.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed add-on to the admin panel we already pay for. It turns our KPI cards from static snapshots into self-refreshing tiles, so the people making daily calls on support load, launch health, and revenue see current numbers without asking engineering. No new servers, no new vendor, no new license. Estimated effort: a one-day spike to validate, then a config change per metric.

For engineering: It's a drop-in Nova metric extension that adds interval polling to existing metric cards — no websockets, queues, or infrastructure. The honest caveat is maintenance: 7 stars, 0 dependents, last release mid-2023. So the recommendation isn't "add the dependency," it's "vendor or fork it, pin it, and own ~a few hundred lines." If compatibility with our Nova version doesn't hold on the first try, we build the equivalent in-house in one to two days — the decision either way is cheap and reversible.

The ask: approve a one-day spike to validate compatibility and polling behavior against two or three of our existing metrics in staging. Success criteria: cards refresh on our chosen interval, no measurable load increase on the metrics endpoints, no console or server errors over 24 hours. Then we either adopt the fork or implement in-house, and the decision is closed inside a week.