Laravel Slower Laravel Package

Technical Evaluation

Architecture fit. Laravel Slower is a developer-tooling add-on that sits in the same architectural slot as Telescope and Horizon: a package-owned route group, a published migration into the host application's database, a service-provider-registered DB::listen hook, and a gate (viewSlower) controlling access. It imposes no abstraction on application code — nothing to extend, no interfaces in your domain, no changes to models or queries. That is the right shape for this class of tool: the blast radius of adoption is a service provider, one table, and a config file. The substantive architectural coupling is outward: query capture flows to an optional third-party LLM through Prism (the Laravel AI package), so the package effectively extends your data-processing perimeter to an external provider. That is an architecture decision, not a package decision, and it is the one item a TPM must escalate rather than decide.

Integration feasibility. Very high on the mechanical axis. composer require, publish migrations, migrate, open /slower — minutes to first value in a local environment, with no npm, CDN, or asset publishing. Config is env-driven and optional. The dashboard reuses the Telescope/Horizon authorization idiom, so it will be immediately legible to any Laravel team. Realistic effort is half a day for a correct non-local rollout (threshold tuning, sample rate, gate definition, queue worker, retention schedule, secrets) plus whatever security/legal review the AI payload triggers. There is no migration of existing data; the only backfill is slower:fingerprint, which is chunked and idempotent.

Technical risk.

• Data egress and residency (highest). Even in the safe default, the payload includes parameterized SQL, table and column names, index definitions, origin context, and an EXPLAIN plan — the last of which the README explicitly warns may echo literals on some drivers. Schema names are themselves disclosure (patient_records, billing_tokens). In a regulated environment this requires a provider DPA, a documented redactor implementing PayloadRedactor, and possibly a self-hosted model via the custom driver to keep traffic in-VPC.
• Sensitive data at rest. slow_logs accumulates SQL and bindings containing PII and secrets in your primary database. This is a new regulated data store with no encryption or access control beyond the gate. Retention is an operator responsibility.
• Synchronous analysis by default. The dashboard advertises "analyze up to analyze_pending_limit (10) at once." Ten sequential 30-second LLM round-trips inside an HTTP request is a request-timeout incident. Queued analysis must be treated as mandatory, not optional, in any shared environment.
• Vendor and maintainer risk. 415 stars, zero dependents, and an effectively single-maintainer project, with a transitive dependency on Prism (itself young and fast-moving). MIT plus a small, boring codebase (listener, controllers, Blade views) makes a fork cheap — quantify the exit as low, but non-zero.
• Listener coexistence. DB::listen is a global hook; stacking it with Telescope, Pulse, and Debugbar means several listeners holding resolved SQL and bindings per query. Overhead is per-query, not per-slow-query.
• Silent incompleteness. Sampling and max_per_execution deliberately make counts approximate. A dashboard showing partial data with no visible "sampled" badge is a decision-support hazard.

Key questions.

1. Is the slow_logs connection configurable so it can target a separate database, or does it always write to the default connection?
2. What is the unit of "one execution" for SLOWER_MAX_PER_EXECUTION inside long-lived queue:work and Octane processes — the job/request, or the process lifetime?
3. Does the package ever issue EXPLAIN ANALYZE (which executes on Postgres), or strictly non-executing EXPLAIN? On which connection and with what privileges?
4. Does slower:clean ship scheduled, or must the operator wire it into routes/console.php?
5. Does the viewSlower gate cover every dashboard route, including AJAX/JSON endpoints used by the Analyze and delete actions?
6. Which Prism version is pinned, and can the provider be swapped without touching Slower config?
7. What is the token cost per analysis, and are prompts stable enough to benefit from provider-side caching?
8. Who is the second contributor, and is there CI covering the capture path?

Integration Approach

Stack fit. Native. PHP 8.3+ and Laravel 11–13 covers any actively maintained codebase; the package assumes only what every Laravel app already has (a database, an artisan console, optionally a queue). For teams already running Horizon, the gate pattern and /slower path will feel like an extension of existing tooling rather than a new platform. The custom-driver escape hatch is the differentiator for enterprise: it converts a "send our schema to OpenAI" conversation into a "point at our approved inference endpoint" conversation.

Migration path. Purely additive — no changes to application code, no schema changes to existing tables. Adoption is composer require → publish and run the migration → publish config only if defaults need overriding → define the gate → schedule slower:analyze and slower:clean. Removal is symmetric: disable routes via SLOWER_DASHBOARD_ENABLED=false, drop slow_logs, remove the provider entry from config/app.php. Back out cost is near zero, which is the strongest argument for running a bounded pilot rather than a committee review.

Compatibility. Check three edges before committing: (a) coexistence with Telescope/Pulse/Debugbar listeners in the same environment; (b) MySQL vs Postgres EXPLAIN semantics and privileges for the app's DB user; (c) the existing observability surface — if the team already runs Pulse or an APM with slow-query capture, Slower must be positioned as the remediation layer (fingerprinted grouping + origin + AI suggestion), not a replacement for metrics, or it becomes a redundant tab nobody opens.

Sequencing.

1. Week 1 — local/staging pilot. Install with AI enabled, low threshold, sample rate 1.0, no queue. Evaluate recommendation quality against a real slow query your team already understands. This is a pass/fail gate on the package's core claim.
2. Week 2 — governance. Security review of the payload contract; decide provider, region, and redactor; draft the retention policy for slow_logs. If this stalls, proceed to step 3 anyway with AI disabled — capture and grouping retain most of the value.
3. Week 3 — production, capture-only. Deploy with SLOWER_ANALYZE_QUEUE set, SLOWER_SAMPLE_RATE tuned to observed slow-query volume, gate restricted to a named engineer group, slower:clean --days=30 scheduled.
4. Week 4 — AI, queued and capped. Enable analysis as a scheduled nightly batch over the top groups rather than on-demand button clicks. Wire SlowQueryFirstSeen to the team channel so new query shapes surface without anyone visiting the dashboard.
5. Ongoing — triage ritual. A weekly review of the top ten groups ranked by occurrences × average duration. Without this, the package is a data collector with no consumer.

Operational Impact

Maintenance. Low and bounded. The code surface is small and conventional; upgrades are Composer bumps gated on Laravel/PHP version alignment and, on fingerprint-algorithm changes, a re-run of slower:fingerprint. The real recurring work is database hygiene: slow_logs growth, index maintenance on that table, and keeping the retention job alive. Budget roughly 0.1 FTE for the first quarter, falling after that, plus the standing cost of monitoring a single-maintainer dependency for abandonment signals.

Support. No commercial backing and no SLA. Support is GitHub issues plus a thorough README and changelog. In practice the README's privacy and production-control sections are strong enough that most questions are self-service. The compensating control for bus factor is license and size: MIT plus a small, readable codebase means a fork is a day of work, not a quarter. Keep the dependency pinned and record the fork decision in the runbook.

Scaling. Two independent axes. Storage: captured rows scale as requests × slow-query fraction × sample rate; on a high-QPS system this is the binding constraint and the reason SLOWER_SAMPLE_RATE and slower:clean are not optional. Writing that volume to the primary database is write amplification you are choosing to accept — verify whether a separate connection is configurable before assuming you can isolate it. AI spend: cost scales with analyzed queries, controllable via analyze_pending_limit, nightly batching instead of button-driven analysis, and analyzing grouped shapes rather than individual events so one LLM call covers 10,000 occurrences.

Failure modes and mitigations.

• Provider outage or rate limit → analysis degrades, capture continues; acceptable. Emit an alert on repeated analysis failures so the backlog is visible.
• Synchronous analysis timing out a request → enforce queued analysis in every shared environment.
• slow_logs write failure (full disk, dropped table) → the built-in circuit breaker backs off 60 seconds and still report()s; confirm this path is alarmed, since a silently tripped breaker means no data.
• Primary database saturation from capture volume → sample rate down, retention tightened, separate connection if available.
• PII exposure → gate, retention, and redactor together; the redactor contract throwing on misconfiguration is the right behavior and should be tested in staging.
• Silent truncation via max_per_execution on runaway jobs → document that counts are approximate; alert if the cap trips repeatedly, which itself indicates a query-in-a-loop defect.
• Upgrade regression on fingerprint versioning → re-run slower:fingerprint as a release step, and expect the Grouped view to reshuffle temporarily.

Ramp-up. Nearly flat for an engineer already fluent in Laravel: the mental model is Telescope plus a /slower page, and the origin table (route / job / command / file:line) makes recommendations concrete enough that a mid-level developer can act on them without an APM expert. Time to competent use is under a day. The real ramp-up risk is organizational, not technical — the package is an opinionated prompt for a remediation habit, and if no one owns the weekly triage, adoption decays into an unused dashboard with a growing table. Assign the owner before installation, not after.