Memory Scanner Laravel Package

Product Decisions This Supports

• Build vs. buy for memory diagnostics. This package replaces the homegrown habit of sprinkling memory_get_usage() / memory_get_peak_usage() calls and Log::info() lines through jobs and controllers. Adopting it is a small, reversible buy decision; a PM can approve it as a dev-only dependency rather than sponsoring an internal tooling project.
• Incident triage and postmortems. When a queue worker, Horizon job, scheduled command, or Laravel Octane worker dies with Allowed memory size exhausted, this gives engineers a structured way to attribute memory growth to a code path instead of guessing. That directly shortens MTTR on a recurring, high-visibility outage class.
• Capacity planning and worker sizing. Findings feed concrete decisions: how many workers per box, what memory_limit to set, whether to chunk an export, whether a job must be released in batches. These are roadmap-adjacent infra decisions that are otherwise made on vibes.
• Prioritizing memory-related tech debt. A profile that shows a report/export endpoint or an import pipeline leaking or ballooning gives you evidence to slot a refactor into the roadmap ahead of feature work, with a defensible "this is why checkout 500s on Mondays" narrative.
• Definition of done and CI budgets. The package can back a memory assertion in a test or a CI smoke check ("this endpoint must stay under N MB"), turning a vague non-functional requirement into a gateable one.
• Representative use cases: long-running queue/console commands, batch imports and CSV/PDF generation, image processing, large Eloquent result sets, and Octane/Swoole request lifecycle leaks.
• Where it should not drive decisions: it is a development-time diagnostic, not an APM. It does not produce production traces, dashboards, or historical trends, so it should not be used to justify SLO or observability-spend decisions.

When to Consider This Package

Consider it when most of these are true:

• You have a recurring or suspected memory problem — OOM crashes, workers recycling unexpectedly, memory_limit raised repeatedly as a workaround.
• Your stack is PHP/Laravel with long-running processes (queues, Horizon, Octane, schedulers, big exports) where per-request memory is not naturally bounded.
• You have no profiling tool in place, or your existing tool (Xdebug, Blackfire, Tideways, Datadog/NR APM) is too heavyweight, too costly per seat, or not available in the environment where the bug reproduces.
• You want a low-ceremony, MIT-licensed, dev-only dependency an engineer can add and remove without architecture review.
• You are running a time-boxed spike (a day or two) on a specific leak, not standardizing tooling org-wide.

Look elsewhere when:

• Maturity risk is unacceptable. 18 stars and 0 dependents is thin social proof. Treat it as experimental: pin the version, wrap it behind your own thin abstraction, and do not make a critical workflow depend on it. Vet PHP-version support and Laravel compatibility against your matrix before committing.
• You need production-safe, low-overhead monitoring with history. Use an APM/profiler (Blackfire, Tideways, Datadog, New Relic) or a hosted service.
• The problem is CPU, I/O, or query count, not memory — different tools entirely.
• You need vendor support, SLAs, or long-term maintenance guarantees. This is community tooling from a company that uses it internally (ShipMonk), not a commercial product.
• Your team lacks PHP-internals fluency. Findings still require someone who can read allocation behavior and act on it; the tool shortens the search, it does not replace the skill.

Pragmatic stance: approve for evaluation in a spike, not as a platform dependency. Success criteria are concrete — did it locate the leak, and did the fix hold under load?

How to Pitch It (Stakeholders)

To executives (one paragraph): Memory exhaustion is one of the most common causes of hard-to-reproduce 500s, stuck queue workers, and late-night pages in PHP systems, and it is usually diagnosed by guesswork. This is a free, MIT-licensed, development-only library that lets engineers pinpoint where memory is going instead of raising memory_limit again. Cost is effectively zero (no license, no infrastructure, no runtime footprint in production), the blast radius is small (dev dependency, removable in one line), and the payoff is faster resolution of a specific, recurring outage class plus better-informed worker sizing. The caveat is maturity: it has a small community, so I recommend a time-boxed pilot on one known problem rather than an org-wide standard, and I would not present it as a replacement for paid profiling or APM.

To engineering leads: Simple API, fits the existing Laravel/PHP toolchain, no service to operate, no production instrumentation required — run it locally or in CI against the reproduction. It complements rather than replaces Xdebug or an APM: use it for targeted leak hunts and as a possible memory budget assertion in tests. Risks to accept explicitly: small user base, so budget a short compatibility check on your PHP and Laravel versions, pin the version, and keep the usage behind a small internal wrapper so swapping it out later is cheap.

Framing to avoid: do not sell this as "observability" or "APM." It is a scalpel for a specific class of bug. The pitch is cheap, reversible, targeted risk reduction on memory-related incidents — not a platform investment.