Let’s Talk About That 3 AM Wake-Up Call

You know the feeling. Your phone buzzes at 3 AM, someone on the team pings you saying the app is slow, users are complaining, and you’re staring at a screen full of logs trying to figure out what the heck is going on.

I’ve been there more times than I’d like to admit. And for a long time, my go-to toolkit was just… log files and gut instinct. Not great.

That changed when I started using Laravel Pulse. Honestly, it’s one of those tools where once you start using it, you can’t imagine going back. It gives you a real-time dashboard showing exactly what your Laravel app is doing right now — which queries are slow, which jobs are failing, what your cache hit rate looks like, and a lot more.

In this guide, I’m going to walk you through everything you need to know about Laravel Pulse. We’ll cover what it is, how to install it, how to use the dashboard, and even how to build your own custom monitoring cards. Whether you’re a solo developer or working on a team, this is the kind of tool that’ll make your life noticeably easier.

So, What Exactly Is Laravel Pulse?

Laravel Pulse is an official first-party package from the Laravel team — meaning it’s built and maintained by the same people who build the framework itself. That alone gives it a level of trust and polish that a lot of third-party packages just can’t match.

It was shipped in late 2023 and has been gaining serious traction ever since. The idea behind it is pretty straightforward: give developers a lightweight, production-safe way to monitor their application’s health without needing to pay for expensive tools like Datadog or New Relic.

I like to think of it this way — if your application were a car, Laravel Pulse would be the dashboard. It doesn’t drive the car for you, but it tells you when you’re running low on fuel, when the engine’s overheating, and when something’s seriously wrong before you break down on the highway.

It’s free, it’s open source (MIT licensed), and it installs in about five minutes. I genuinely can’t think of a good reason not to use it on every Laravel project.

What Can Laravel Pulse Actually Do?

Let me walk through the features one by one, because there’s more packed in here than you might expect.

Real-Time Application Metrics

The first thing you’ll notice when you open the Pulse dashboard is that it’s live. Not “refresh every five minutes” live — actually live. You can watch traffic patterns shift in real time, which is incredibly useful during deployments or when you’re investigating an incident.

Database Query Monitoring

This one has saved me hours of debugging. Pulse tracks slow database queries — any query that takes longer than your configured threshold — and surfaces them right on the dashboard. You get the query itself, how long it took, and exactly which file and line triggered it.

If you’ve ever spent an afternoon hunting down an N+1 query problem, you’ll immediately understand why this feature is gold.

HTTP Request Tracking

Pulse logs every incoming request: the route, status code, response time, and the authenticated user if there is one. At a glance you can see which endpoints are getting hammered and which ones are dragging their feet.

Cache Monitoring

A card dedicated to cache hits and misses. If your hit rate is consistently low, something’s off — maybe your cache keys are wrong, your TTL is too short, or you’re just not caching the right things. Pulse makes that obvious.

Queue Monitoring

For most Laravel apps, queues are doing a ton of invisible work in the background. Pulse gives you visibility into that — job throughput, failure rates, queue depth over time. If the queue is getting backed up, you’ll see it before your users feel it.

Performance Insights

Beyond individual metrics, Pulse gives you a broader picture of app performance: average response times, memory usage trends, and how things are changing over time. Super useful for catching gradual degradation that wouldn’t trigger an immediate alarm.

Custom Cards

This is my personal favorite feature. If the built-in cards don’t cover something you care about, you can build your own. Want to track how many checkout attempts happen per minute? Or monitor the number of active API tokens? You can do that. We’ll get into the specifics later in this post.

Installing Laravel Pulse (It’s Easier Than You Think)

Requirements

Before you start, make sure your environment is ready:

• PHP 8.2 or higher
• Laravel 10.x or higher (works great on Laravel 11 too)
• MySQL, PostgreSQL, or SQLite
• Composer installed

Step 1: Pull It In via Composer

From your project root, run:

composer require laravel/pulse

composer require laravel/pulse

That’s it for installation. Seriously. Composer handles everything.

Step 2: Publish the Config and Views

Next, publish Pulse’s config file and frontend assets so you can customize them:

php artisan vendor:publish --provider="Laravel\Pulse\PulseServiceProvider"

php artisan vendor:publish --provider="Laravel\Pulse\PulseServiceProvider"

This drops a config/pulse.php file into your project and publishes the dashboard view. You’ll want both.

Step 3: Run the Migrations

Pulse needs a few tables in your database to store the metrics it collects. Run:

php artisan migrate

php artisan migrate

If you want Pulse to use a separate database connection (recommended for production — more on that later), you can configure that in config/pulse.php before running this command.

Step 4: Open the Dashboard

By default, the Pulse dashboard lives at /pulse on your app. Head there in your browser:

http://your-app.test/pulse

http://your-app.test/pulse

You’ll need to set up access control first though, or you’ll hit a 403. Let’s do that next.

Configuring Pulse the Right Way

The Config File

The config/pulse.php file is where most of your customization happens. Here’s the part you’ll tweak most often — the recorders section and the data retention settings:

// config/pulse.php
return [
    'ingest' => [
        'trim' => [
            'lottery' => [1, 1000],  // trim old data 1 in 1000 requests
            'keep'    => '7 days',    // how long to keep data
        ],
    ],
    'recorders' => [
        \Laravel\Pulse\Recorders\CacheInteractions::class => [],
        \Laravel\Pulse\Recorders\Exceptions::class        => [],
        \Laravel\Pulse\Recorders\Queues::class            => [],
        \Laravel\Pulse\Recorders\Requests::class          => [],
        \Laravel\Pulse\Recorders\SlowQueries::class => [
            'threshold' => 1000,  // ms — flag anything over 1 second
        ],
    ],
];

// config/pulse.php
return [
    'ingest' => [
        'trim' => [
            'lottery' => [1, 1000],  // trim old data 1 in 1000 requests
            'keep'    => '7 days',    // how long to keep data
        ],
    ],
    'recorders' => [
        \Laravel\Pulse\Recorders\CacheInteractions::class => [],
        \Laravel\Pulse\Recorders\Exceptions::class        => [],
        \Laravel\Pulse\Recorders\Queues::class            => [],
        \Laravel\Pulse\Recorders\Requests::class          => [],
        \Laravel\Pulse\Recorders\SlowQueries::class => [
            'threshold' => 1000,  // ms — flag anything over 1 second
        ],
    ],
];

You can tune the slow query threshold to whatever makes sense for your app. If your app typically answers queries in under 100ms, you might want to lower that threshold to 300ms or even 200ms.

Locking Down Dashboard Access

Please don’t skip this step. The Pulse dashboard shows you information you don’t want random users seeing. There are two ways to restrict it.

Option 1 — define the gate in your AuthServiceProvider:

use Illuminate\Support\Facades\Gate;

Gate::define('viewPulse', function ($user) {
    return in_array($user->email, [
        'you@yourcompany.com',
        'yourteamlead@yourcompany.com',
    ]);
});

use Illuminate\Support\Facades\Gate;

Gate::define('viewPulse', function ($user) {
    return in_array($user->email, [
        'you@yourcompany.com',
        'yourteamlead@yourcompany.com',
    ]);
});

Option 2 — use the Pulse facade in your AppServiceProvider, which I personally prefer because it’s more flexible:

use Laravel\Pulse\Facades\Pulse;

Pulse::auth(function ($request) {
    return $request->user()?->hasRole('admin');
});

use Laravel\Pulse\Facades\Pulse;

Pulse::auth(function ($request) {
    return $request->user()?->hasRole('admin');
});

Customizing the Dashboard Layout

You can publish the dashboard Blade view and rearrange cards however you like:

php artisan vendor:publish --tag=pulse-dashboard

php artisan vendor:publish --tag=pulse-dashboard

This creates resources/views/vendor/pulse/dashboard.blade.php. The dashboard uses a 12-column grid, and each card is a Livewire component. Drag the components around in the file to change the layout. Pretty intuitive once you see it.

Making Sense of the Pulse Dashboard

When you first open the dashboard, you might feel like you’re looking at a lot of data at once. Let me break down what each card is actually telling you.

The Requests Card

This shows you HTTP request volume over time. What you’re looking for here are sudden spikes (maybe a bot hit your site, or a marketing email went out) and the relationship between request volume and response time. If response times go up when request volume goes up, you might have a scaling issue.

The Slow Queries Card

In my experience, this is the card you’ll check most after a deployment. Any query over your threshold gets listed here with full details. The file and line number mean you can usually track down the offending code in under a minute. I’ve fixed queries that were taking 4 seconds down to 40ms just because Pulse made them visible.

The Exceptions Card

Shows you unhandled exceptions grouped by type. A sudden jump in a specific exception class after a deployment? That’s almost always the deployment. This card makes it really obvious.

The Queues Card

Shows job throughput and failure rates. If the failure rate climbs or the queue depth stops shrinking, your workers have a problem. Could be a bad job class, a third-party service that’s down, or simply not enough worker processes running.

The Cache Card

Cache hits vs misses. A healthy ratio is something like 80-90% hits or better. If you’re seeing a lot of misses, dig into which cache keys are being missed. Sometimes it’s as simple as a typo in a cache key name, or a TTL that’s too aggressive.

Building Your Own Pulse Cards

Alright, this is where things get fun. Let’s say you want to track a metric specific to your business — like how many orders are being placed per hour, or how many users are currently active. Pulse lets you build custom cards for exactly this.

Here’s a practical example: a card that counts new user registrations per hour.

Step 1: Create the Recorder

The recorder is what actually captures the data. It listens for an event and stores the metric:

namespace App\Pulse\Recorders;

use Laravel\Pulse\Recorders\Concerns\Throttling;
use Laravel\Pulse\Support\Concerns\InteractsWithStorage;

class NewUserRegistrations
{
    use Throttling, InteractsWithStorage;

    public function record(UserRegistered $event): void
    {
        // Store a count of 1 every time a user registers
        $this->storage()->record('new_registrations', 1);
    }
}

namespace App\Pulse\Recorders;

use Laravel\Pulse\Recorders\Concerns\Throttling;
use Laravel\Pulse\Support\Concerns\InteractsWithStorage;

class NewUserRegistrations
{
    use Throttling, InteractsWithStorage;

    public function record(UserRegistered $event): void
    {
        // Store a count of 1 every time a user registers
        $this->storage()->record('new_registrations', 1);
    }
}

Step 2: Create the Livewire Card Component

The card component fetches and displays the aggregated data:

namespace App\Livewire\Pulse;

use Laravel\Pulse\Livewire\Card;
use Livewire\Attributes\Lazy;

#[Lazy]
class NewRegistrationsCard extends Card
{
    public function render()
    {
        $registrations = $this->pulse->aggregate(
            'new_registrations',
            'sum',
            '1 hour'
        );

        return view('livewire.pulse.new-registrations', [
            'registrations' => $registrations,
        ]);
    }
}

namespace App\Livewire\Pulse;

use Laravel\Pulse\Livewire\Card;
use Livewire\Attributes\Lazy;

#[Lazy]
class NewRegistrationsCard extends Card
{
    public function render()
    {
        $registrations = $this->pulse->aggregate(
            'new_registrations',
            'sum',
            '1 hour'
        );

        return view('livewire.pulse.new-registrations', [
            'registrations' => $registrations,
        ]);
    }
}

Step 3: Drop It Into the Dashboard

Open your dashboard.blade.php and add your card anywhere you like:

<livewire:pulse.new-registrations cols="4" />

<livewire:pulse.new-registrations cols="4" />

The cols attribute controls width — 4 takes up a third of the 12-column grid. Simple as that. Your custom metric is now sitting right alongside the built-in ones.

Why Should You Actually Care About This?

I know “yet another monitoring tool” can feel like overkill, especially if you’re a solo dev or working on a smaller project. But here’s what actually changes when you have Pulse installed:

You stop flying blind in production. Log files are reactive. Pulse is proactive. You see issues forming before they become user-facing problems.

Debugging gets way faster. Instead of spending an hour correlating logs from five different places, you open one dashboard and the picture comes together in minutes.

Conversations with your team get easier. When something goes wrong, you can pull up Pulse and point to the exact moment the exceptions spiked or the queue backed up. No more “I don’t know, the logs don’t say much.”

Performance wins are measurable. When you optimize a slow query, you can actually see the before and after in Pulse. That’s satisfying, and it makes the case for doing more optimization work.

It costs nothing. Seriously. Free, open source, first-party quality. That’s rare.

Pulse vs Telescope: Which One Should You Use?

This comes up a lot. People see both tools and wonder if they’re redundant. They’re really not — they solve different problems.

Here’s how they compare side by side:

My honest take: use both. Run Telescope locally when you’re building features and need to inspect individual requests, database queries, mail sends, etc. Run Pulse in staging and production where you care about aggregate health and performance trends. They complement each other — they don’t compete.

A Few Things I’d Do Differently If I Was Starting Fresh

After running Pulse on a few different projects, here’s what I’ve learned the hard way:

Give Pulse its own database connection. If your app is high-traffic, Pulse writes can compete with your main app queries. A dedicated connection (or even a separate lightweight database) fixes this cleanly.

Tune your slow query threshold early. The default of 1000ms is fine to start with, but once you’ve been running for a week, look at your actual query times and lower the threshold accordingly. You’ll catch more issues.

Don’t expose /pulse publicly. I know I mentioned this already, but I’ve seen it happen. Lock it down with proper auth from day one.

Use Redis for the ingest driver in production. For apps with real traffic, the default database ingest driver can become a bottleneck. Switch to Redis and you’ll never think about it again:

// config/pulse.php
'ingest' => [
    'driver' => env('PULSE_INGEST_DRIVER', 'redis'),
],

// config/pulse.php
'ingest' => [
    'driver' => env('PULSE_INGEST_DRIVER', 'redis'),
],

Set a sensible retention period. Seven days is usually plenty. Keeping months of data means your pulse tables grow without much benefit.

Check in on the dashboard after every major deployment, not just when something breaks.

You can also run a quick health check on Pulse itself with:

php artisan pulse:check

php artisan pulse:check

Worth adding that to your deployment checklist.

Real-World Scenarios Where Pulse Genuinely Shines

You Just Deployed a Feature and Users Are Reporting Slowness

Open Pulse, check the slow queries card. If a new query showed up in the last hour with a runtime that wasn’t there before, you’ve likely found your culprit. No digging through logs, no grepping, no waiting for a support ticket with enough detail to actually reproduce the issue.

A Marketing Email Just Went Out to 50,000 Users

Traffic spikes are predictable when you’ve scheduled them, but unpredictable in terms of how the app handles them. Pulse lets you watch the request volume spike in real time and immediately see if response times are holding up or starting to degrade.

Email Notifications Are Taking Forever to Send

The queues card will tell you exactly what’s happening. Is the queue depth growing? Are jobs failing? Are your workers even running? You get answers to all three questions from a single card without touching the server.

Something Mysterious Is Happening to Your Cache

I once spent half a day tracking down a caching bug where we had a typo in a cache key. The cache miss rate on the Pulse dashboard was sitting at 92%. I wouldn’t have caught it nearly as fast without that visual — it just looked like a number somewhere in the 20-30% range during normal operation.

FAQs