Symfony Command Profile Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for CLI observability. This bundle wraps Symfony Console's command lifecycle to capture per-command profiling data (duration, memory, execution context). The decision it informs is whether to hand-roll timing/logging middleware around Artisan and scheduled commands, or adopt a small pre-built bundle and spend the engineering budget elsewhere.
• Prioritizing performance work on scheduled/CLI workloads. Laravel's web requests get the observability tooling by default (Telescope, Pulse, APM agents); artisan, cron-driven commands, and queue-adjacent workers usually do not. Command-level profiling turns "the nightly job feels slow" into a ranked list, which is a roadmap input.
• Scoping an internal developer-experience initiative. If a team owns shared tooling, this is a candidate component for a "command performance dashboard" — cheap to trial, low blast radius, and reversible.
• Version posture / dependency risk. The 0.1.0 release (up from 0.0.2) signals pre-1.0 API churn. The release notes contain only an auto-generated changelog link, so no feature, fix, or breaking change can be verified from this release alone. Treat the version bump as an intent-to-stabilize signal, not as evidence of new capability, and re-read the diff before pinning.

When to Consider This Package

Adopt for evaluation when:

• You have a non-trivial number of Artisan/cron commands and no existing CLI-level profiling.
• Your team is comfortable with Symfony-ecosystem packages — this is a Symfony bundle, not a Laravel package. Laravel runs on Symfony Console, so the underlying instrumentation is relevant, but bundle registration and configuration are not Laravel-native and will need a manual service provider / config bridge. Budget for that glue explicitly.
• You want a time-boxed spike (days, not weeks) to answer "which commands are expensive?" before committing to a heavier APM contract.
• You can pin to an exact version and absorb pre-1.0 churn.

Look elsewhere when:

• You need production-grade, always-on profiling with retention, alerting, and cross-service tracing — use an APM (Datadog, New Relic, Sentry Performance) or Laravel Pulse plus custom recorders.
• The requirement is debugging rather than profiling — Laravel Telescope already covers command inspection natively, with zero integration cost.
• Composer/security policy blocks low-adoption, single-maintainer dependencies, or you require a stable 1.x API contract.
• You need first-class Laravel support: php artisan integration docs, config publishing, facade — none of which a Symfony bundle provides out of the box.

How to Pitch It (Stakeholders)

To executives: We spend most of our monitoring budget on the web tier; batch and scheduled jobs are effectively unmeasured, which is where slow failures hide and where "why was the nightly run late?" becomes an expensive investigation. This is a small, low-cost Symfony bundle that instruments console commands and gives us per-command timing and memory data. The ask is a short, reversible spike — not a platform commitment — to determine whether it's sufficient or whether we need to fund a proper APM tier for background workloads. Note the package is pre-1.0 and maintained by a single publisher, so we would pin the version and keep it behind an interface.

To engineering: This is a Symfony Console profiling bundle (tourze/symfony-command-profile-bundle), now at 0.1.0. Because Laravel's Artisan is built on Symfony Console, the instrumentation surface is compatible, but there is no Laravel-native integration — expect to write a service provider and config bridge yourself. The 0.1.0 release ships no human-readable changelog, so review the diff before adopting. Success criteria for the spike: (1) commands profiled without touching command code, (2) measurable overhead under an agreed threshold on our heaviest command, (3) data lands somewhere we can query. If any of the three fails, we fall back to a thin custom CommandFinished listener — roughly a day of work — and revisit APM.