Filament Memory Tracker Laravel Package

Product Decisions This Supports

• Feature scoping for ops visibility: Gives you a concrete, low-cost way to answer "should queue memory be visible inside the admin panel?" before committing roadmap capacity to a broader observability initiative. It is a cheap probe, not a platform.
• Build vs. buy vs. fork: With ~a few hundred lines of tracking logic and a Filament widget, this is the classic "buy for a week, fork for a quarter" candidate. The decision it informs is usually fork, because the surface area is small and the maintenance burden of an abandoned dependency outweighs reimplementation.
• Incident triage and postmortems: A memory-per-worker view shortens the "why did the queue OOM at 3am" conversation, particularly for long-running workers, queue:work --daemon-style processes, and jobs that leak (PDF generation, image processing, large Eloquent hydration).
• Capacity and infrastructure spend: Repeated upward memory trends across workers are an input to decisions like "add worker replicas," "reduce --max-jobs/--max-time," or "move heavy jobs to a separate queue/container" — all cheaper than vertical scaling.
• Release-gating for risky jobs: If a specific job class correlates with memory growth, that's a signal to prioritize refactoring it (chunking, cursor(), lazy()) over shipping new features on that queue.
• Prioritization input, not a KPI source: Treat it as directional evidence for engineering investment, not as a metric executives should track. There is no retention, alerting, or historical aggregation here.

When to Consider This Package

Adopt (or, more realistically, prototype with) it when:

• You are already running Filament in an internal admin panel and want queue/worker memory visible with near-zero integration effort.
• You are on a Filament version contemporary with the Feb 2023 release (likely v2-era); confirm compatibility before assuming it drops into a v3+ panel — the last release predates Filament v3's general availability, so treat version support as unverified until proven in a spike.
• The audience is internal engineers/ops, not customers, and a dashboard being occasionally wrong or stale is acceptable.
• You need a throwaway diagnostic during a specific investigation (memory leak hunt) rather than a permanent production dependency.
• You are comfortable vendoring/forking the package and owning it.

Look elsewhere when:

• You need alerting, retention, historical trend lines, or per-job attribution — Laravel Horizon (queue metrics/throughput), Laravel Telescope (request/command memory), Sentry, Laravel Nightwatch, or a Datadog/Grafana pipeline are the real answers.
• Maintenance risk is unacceptable: 27 stars and no release since early 2023 means effectively single-maintainer, low-adoption, and likely unmaintained. Bus factor is ~1 and it may already be one.
• You require supported upgrade paths across Laravel/Filament majors — you will be doing that work yourself.
• The dashboard would be customer-facing or SLA-relevant.
• Memory tracking needs to survive process restarts and multi-host deployments with aggregation — this package stores/display locally, not as a time-series.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed dashboard plugin that surfaces how much memory your background job workers are consuming, inside the admin panel your team already uses. It costs essentially nothing to trial and could shorten incident diagnosis for queue crashes. The caveat is material: it's a low-adoption project with no release in over a year, so I recommend a time-boxed spike and, if it proves useful, a small internal fork we own — not a production dependency we inherit. Expected investment: days, not weeks. Expected return: faster triage and better-informed decisions on worker sizing and job refactoring.

To engineering: It's a thin wrapper over PHP memory readings for workers/queues plus a Filament widget. Low integration cost, but unmaintained since Feb 2023 and likely Filament v2-targeted — validate against our Filament version first. If the spike works, plan to vendor it: the code is small, and owning it removes the compatibility and abandonment risk entirely. It does not replace Horizon, Telescope, or our APM; position it as an in-panel convenience view, with real observability staying where it is.