Why I Removed Laravel Pulse (and You Might Not Need It Either)

I had a pulse:check daemon running on my Laravel Forge server for over a year. It was collecting data on slow queries, slow requests, exceptions, cache usage, and server stats. The problem: I was barely looking at any of it, and I already had Sentry doing most of the same work.

Table of contents

What Laravel Pulse actually does

Laravel Pulse is a first-party monitoring dashboard built by the Laravel team. It runs a background daemon (pulse:check) that continuously collects data and stores it in three database tables: pulse_values, pulse_entries, and pulse_aggregates.

The dashboard (at /pulse) shows:

• Slow database queries that exceed a configurable threshold
• Slow HTTP requests and response times
• Slow queued jobs and their durations
• Slow outgoing HTTP requests (external API calls)
• Exceptions your app throws
• Server stats like CPU and memory usage
• Cache hit/miss ratios
• Application usage by user

It’s a reactive tool. The data sits there waiting for you to check. If a query starts taking 500ms, Pulse records it — but nobody taps you on the shoulder about it.

How Pulse compares to Sentry

Sentry is a third-party error tracking and performance monitoring platform. It overlaps with Pulse in places, but takes a different approach.

Sentry emails me when something breaks. Pulse waits for me to visit /pulse and notice it myself.

The question I asked

When I noticed the pulse:check process still running on my Forge server, I asked:

My old Laravel Forge server has a background job running for Laravel Pulse, do I still need this? What does it do?

The answer was clear: since I already had Sentry for error tracking and wasn’t using Pulse for slow query analysis, it was redundant — consuming server resources for data nobody checked.

Since you already have Sentry for error tracking and Horizon for queue monitoring, Pulse is somewhat redundant unless you specifically use it for slow query/request analysis. If you’re not checking the Pulse dashboard regularly, you can safely stop the pulse:check process on Forge and save the server resources.

That settled it. YAGNI applies to monitoring tools too — if you’re not actively using a tool, it’s just overhead.

How to remove Laravel Pulse

Here’s the step-by-step process. Five files changed, one file created.

1. Stop the daemon

On Laravel Forge, delete or disable the pulse:check background process first. Do this before deploying the code changes.

2. Remove the Composer dependency

In composer.json, remove the laravel/pulse line:

- "laravel/pulse": "^1.5",

3. Delete the config file

Delete config/pulse.php. This was published when you first installed Pulse and contains all the recorder configuration.

4. Delete the dashboard view

If you customised the Pulse dashboard, delete the published view:

resources/views/vendor/pulse/dashboard.blade.php

5. Remove the authorization gate

Pulse uses a viewPulse gate to control who can access the dashboard. Remove it from your AppServiceProvider:

- Gate::define('viewPulse', function (User $user) {
-     return $user->is_admin;
- });

Clean up any unused imports (Gate, User) that were only there for this gate.

6. Create a migration to drop the tables

Pulse stores data in three tables. Create a migration to remove them:

return new class extends Migration
{
    public function up(): void
    {
        Schema::dropIfExists('pulse_values');
        Schema::dropIfExists('pulse_entries');
        Schema::dropIfExists('pulse_aggregates');
    }

    public function down(): void
    {
        //
    }
};

Important: The down() method is a no-op — this migration is not reversible. Take a database backup before running it in production.

pg_dump -U forge my_app_pg > ~/database_backup.sql

7. Run a verification pass

After making the changes, search the entire codebase for any remaining Pulse references:

grep -r "pulse\|Pulse" --include="*.php" --include="*.json" --include="*.blade.php" .

Watch out for false positives — Tailwind’s animate-pulse CSS class will match but is unrelated to Laravel Pulse.

Deployment order

1. Stop the pulse:check daemon on your server
2. Take a database backup
3. Deploy the code changes
4. Run composer install to remove the package
5. Run php artisan migrate to drop the tables

When you should keep Pulse

Pulse is still a good tool. It’s a good fit if:

• You don’t have Sentry (or a similar tool) and want basic monitoring for free
• You actively use slow query analysis to optimise database performance
• You want server CPU/memory charts without setting up separate infrastructure monitoring
• Your team checks the dashboard regularly as part of their workflow

The point isn’t that Pulse is bad. It’s that running two monitoring tools when you only check one is wasted resources.

What would Taylor Otwell do?

Taylor built Pulse to give Laravel developers a free, first-party monitoring option. But Laravel’s whole approach favours the simplest tool that solves the problem. If Sentry already covers your monitoring needs and you’re not checking the Pulse dashboard, remove it. One fewer daemon, three fewer tables, and a simpler deploy.