Debugging Laravel performance in production

The safe sequence: (1) reproduce locally with seeded data that matches production shape, (2) use Laravel Telescope or Clockwork in staging to identify the bottleneck layer (app code, DB, cache, external HTTP), (3) add targeted instrumentation or APM visibility in production, (4) verify the fix lands before removing the instrumentation. Avoid running debuggers or tinker on production — use APM-level traces instead.

Get a per-request trace of the slow endpoint. APMs give you this: the request is broken into spans (DB queries, cache calls, external HTTP, view rendering) with durations. The largest span is the bottleneck. In 80%+ of cases it's DB queries — usually an N+1 or a missing index. For the other 20%, look at external HTTP first, then view rendering, then cache misses.

For call-level profiling yes — Xdebug's profile output loaded into KCacheGrind or Qcachegrind shows where time is spent at the PHP function level. Don't run Xdebug in production — its overhead is too high. Use it locally with a reproduction of the slow production case. For production-safe profiling, use an APM or PHP's lightweight SPX profiler.

Compare p95 latency per route before and after the deploy timestamp. If p95 for specific routes jumped immediately after deploy, the deploy is the cause. Look at the diff since the last deploy for changes to the affected controllers, Eloquent queries, or middleware. Roll back if the regression is severe while you investigate.

Yes, but carefully. EXPLAIN ANALYZE actually runs the query — safe for SELECTs, dangerous for anything that mutates state. For write queries, use EXPLAIN (without ANALYZE) which returns the plan without executing. Compare plans between expected (from local reproduction) and actual (production) — differences in index usage or join order often explain slowness.

Log peak memory per request with request context (route, user). Aggregate by route to find outliers. For individual problematic requests, reproduce locally with the same input and use PHP's memory_get_usage at key points to narrow down where the spike happens. See our memory-usage guide.

Common causes: (1) a cache that warmed up during deploy is now cold after eviction, (2) database statistics gone stale causing the query planner to pick a bad plan (run ANALYZE), (3) a cron job running in-process that wasn't there before, (4) autoscaling bringing up new workers without connection pool capacity, (5) a third-party API you depend on went slow. APM per-request traces distinguish these fast.

Three practices: (1) seed staging from anonymized production data so you can reproduce realistic bottlenecks, (2) invest in an APM that records enough context to debug from traces alone, (3) set per-route latency SLOs and alert on regressions — you catch issues before they need live debugging. Debugging in prod is what you do when the other three fail.