Laravel Time Machine: Find Where Your Laravel Request Is Spending Time

-

 

Laravel Time Machine: Find Where Your Laravel Request Is Spending Time


Have you ever looked at a slow Laravel request and wondered:

“Where exactly is the time going?”

Is it middleware? Routing? Controller logic? Database queries? An external API?

I built Laravel Time Machine to make answering that question easier.

What is Laravel Time Machine?

Laravel Time Machine is a lightweight request lifecycle profiler for Laravel.

Instead of adding microtime() calls throughout your code or trying to guess where the bottleneck is, it gives you a visual timeline of the request lifecycle.

You can see:

  • 🚀 Application boot time

  • 🔐 Middleware execution

  • 🛣️ Routing

  • 🎯 Controller execution

  • 🗄️ Database queries

  • 📤 Response handling

  • ⏱️ Request termination

  • 💾 Memory usage

  • 🐌 Slow requests and queries

The project is open source and currently supports Laravel 8 through 13.

Why I built it

When debugging performance issues, developers often start adding temporary timing code:

$start = microtime(true);

// Some code...

logger(microtime(true) - $start);

It works, but it becomes repetitive very quickly.

I wanted something where I could simply install a package, open a dashboard, and immediately see where the request spent its time.

That's where Laravel Time Machine comes in.

A visual request timeline

Every request gets a Gantt-style timeline showing the different stages of the Laravel lifecycle.

You can quickly identify whether the bottleneck is happening during:

Bootstrap → Middleware → Routing → Controller → Response → Termination

Database queries are also shown with their execution time, making slow queries easier to spot.

Custom instrumentation

You can also measure your own application code.

For example:

use Jaydeep\LaravelTimeMachine\Facades\TimeMachine;

TimeMachine::mark('cache primed');

$report = TimeMachine::measure('generate-report', function () {
    return Report::build();
});

Or manually track an external API call:

TimeMachine::startSpan('external-api');

$response = Http::get('https://api.example.com');

TimeMachine::endSpan('external-api');

These custom spans appear alongside the Laravel lifecycle timeline.

No database required

One of the things I intentionally wanted to keep simple was storage.

Laravel Time Machine stores profiles as JSON files inside:

storage/time-machine

There are no database tables and no migrations required.

Installation

Installing it is straightforward:

composer require jaydeep/laravel-time-machine

Then run your Laravel application and open:

/time-machine

When APP_DEBUG=true, profiling is enabled by default.

Laravel Time Machine vs Telescope

Laravel Telescope is an excellent tool for broader Laravel application monitoring.

Laravel Time Machine has a narrower goal:

Understand the performance of individual HTTP requests.

It focuses on request lifecycle timing, SQL queries, and a visual timeline without requiring database storage for the profiles.

When should you use it?

Laravel Time Machine can be useful when:

  • Your Laravel endpoint suddenly becomes slow

  • You want to find slow middleware

  • You're investigating N+1 queries

  • A controller is taking longer than expected

  • You want to understand an unfamiliar Laravel application

  • You're profiling an API

  • You want to understand the Laravel request lifecycle

Open Source

I built Laravel Time Machine as an open-source project and would love feedback from the Laravel community.

⭐ GitHub: Laravel Time Machine on GitHub

⬇️ Packagist: Laravel Time Machine on Packagist

🚀 Laravel News: Laravel Time Machine on Laravel News


If you try it, I'd love to hear:

What would you add to the profiler?

Performance profiling is much easier when you can see where the time actually went instead of guessing.

#Laravel #PHP #LaravelDeveloper #OpenSource #WebPerformance #PerformanceOptimization #DevTools #jaydeepgadhiya #laravel-timemachine

Also Read : 10 Laravel Tips That Will Save You Hours of Development Time 

Comments

Post a Comment

Popular Posts

I Let AI Write My Laravel Service Layer — It Worked… Until I Understood What It Actually Did

-
Image
I tried something dangerous. I asked AI to generate a full Laravel service layer: Repository Service class DTO Validation Controller Tests It generated everything in seconds. Clean code. Solid structure. Proper dependency injection . At first, I was impressed. Then I looked deeper. 🤖 The Illusion of Architectural Intelligence AI generated this:     class OrderService     {         public function __construct (             protected OrderRepository $repository         ) {}         public function create ( array $data ): Order         {             return $this -> repository -> create ( $data );         }     }     Looks clean. But notice something subtle: The service is just forwarding calls. No business boundaries . No domain modeling . Just ab...
Read more

How Laravel’s Service Container Resolves Dependencies Automatically

-
Image
 One of the most powerful but least fully understood parts of Laravel is the Service Container . Many developers use it every day without realizing it. Every time Laravel automatically injects a dependency like this:     public function __construct ( UserService $userService )     {         $this -> userService = $userService ;     } Laravel is using its Service Container to resolve the dependency automatically. But how does this actually work internally? Let's go deeper. 🧩 What Is Laravel's Service Container? Laravel’s Service Container is essentially an advanced dependency injection container . It handles: Class instantiation Dependency resolution Interface binding Singleton management Automatic dependency injection Internally, it relies heavily on PHP Reflection . 🔍 Example: Automatic Dependency Resolution Imagine we have a service:          class PaymentService ...
Read more