{"id":194,"date":"2026-05-05T05:04:46","date_gmt":"2026-05-05T05:04:46","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/laravel-pulse-production-what-i-use-what-i-turned-off\/"},"modified":"2026-05-05T05:04:46","modified_gmt":"2026-05-05T05:04:46","slug":"laravel-pulse-production-what-i-use-what-i-turned-off","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/laravel-pulse-production-what-i-use-what-i-turned-off\/","title":{"rendered":"Laravel Pulse in Production: What I Use, What I Turned Off"},"content":{"rendered":"

Confession: I avoided Laravel Pulse for the first six months it was out. The dashboard screenshots looked great, but I already had Laravel Telescope wired up and a Grafana board that nobody ever opened. Adding another monitoring tool felt like the project equivalent of buying another notebook to fix the fact that I never write in any of them.<\/p>\n

Then the support inbox started filling up with “the app is slow on Tuesdays” and I had no good way to point at why. Telescope is great for one request, useless for trends. Grafana told me CPU was fine. I needed something between those two.<\/p>\n

Pulse turned out to be exactly that. I wired it into a Laravel 12 app on a small Hetzner VPS and let it run for six weeks. Some of it was boring. A few bits caught real problems, and a couple of defaults needed disabling before they bit me. Here’s what actually happened.<\/p>\n

What Pulse actually is (the thing the readme glosses over)<\/h2>\n

Pulse is a first-party performance dashboard that lives inside your Laravel app. It records slow queries, slow jobs, slow requests, exceptions, cache hit ratios, queue throughput, and a few other things. Everything goes into your database (you can use a separate connection, more on that), and the dashboard renders at \/pulse<\/code>. The official docs<\/a> cover install in five minutes.<\/p>\n

The bit I missed for a while: Pulse isn’t really a logging tool. It’s a sampling tool. Every record it stores has been aggregated into rolling buckets. So when you look at “slow queries” you’re not seeing every slow query, you’re seeing the top N by aggregated execution time over the window you picked. That’s why the dashboard stays fast even when your app doesn’t.<\/p>\n

The docs do mention this. It still took me a couple of days to internalise it.<\/p>\n

What I actually look at in the dashboard<\/h2>\n

I dropped about half the cards from the default layout. The ones I kept:<\/p>\n

    \n
  1. Slow Queries<\/strong> \u2014 by far the most useful card, because the SQL shows up next to the call site.<\/li>\n
  2. Slow Jobs<\/strong> \u2014 caught a queue job that was loading every user’s relations because of a missing with()<\/code>.<\/li>\n
  3. Exceptions<\/strong> \u2014 overlaps with Sentry, but Pulse groups them by class plus location, which is a nicer first look.<\/li>\n
  4. Cache<\/strong> \u2014 hit ratios per key. Surprisingly useful. I had a key with a 4% hit rate that I’d assumed was hot.<\/li>\n
  5. Usage by User<\/strong> \u2014 the one I check on bad days.<\/li>\n<\/ol>\n

    The cards I dropped: Servers, Storage, Slow Outgoing Requests (we don’t make many), and the Application Usage card. They’re fine, I just don’t use them.<\/p>\n

    The recorders I turned off (and why)<\/h2>\n

    This is the section I wish I’d had on day one.<\/p>\n

    \/\/ config\/pulse.php\n'recorders' => [\n    Recorders\\SlowQueries::class => [\n        'sample_rate' => 0.1,\n        'threshold' => 250, \/\/ ms\n        'ignore' => [\n            '\/(.*pulse_.*)\/',     \/\/ don't record Pulse's own queries\n            '\/(.*telescope_.*)\/', \/\/ or Telescope's\n        ],\n    ],\n\n    Recorders\\SlowOutgoingRequests::class => false, \/\/ disabled\n],\n<\/code><\/pre>\n
    Two changes worth flagging.<\/p>\n
    sample_rate: 0.1<\/code> for slow queries. The default is 1.0. On a busy app that’s a write-amplifier: every slow query becomes a database write. Sampling at 10% kept the resolution I needed without doubling DB writes.<\/p>\n
    threshold: 250<\/code>. The default is 1000ms. That’s too lax for most web requests. I dropped it to 250 and immediately saw a WHERE ... LIKE '%foo%'<\/code> query in a user search I’d forgotten about.<\/p>\n
    Also: explicitly ignore Pulse’s own tables. If you don’t, and you put Pulse on the same database as your app, the dashboard will start recording itself. Not catastrophic, but it pollutes your top-N for no reason.<\/p>\n
    Pulse vs Telescope: I run both, but for different things<\/h2>\n
    I keep seeing this framed as if you have to pick one. I run both.<\/p>\n
    Telescope<\/a> is the per-request inspector. When a customer reports “this page is broken”, Telescope is where I go. It records every query, every cache call, every event, every exception, for that one request.<\/p>\n
    Pulse is the across-time aggregator. When I want to know “which queries were slow last week”, Pulse is where I go.<\/p>\n
    They overlap (both can record exceptions), but the use cases are different enough that I don’t feel bad running both. Telescope is on its own database connection so it doesn’t compete with the app. Pulse uses the main connection because the writes are sampled.<\/p>\n
    If you have to pick one for a small app, pick Pulse. Telescope is a heavier tool that pays off only when something breaks. Pulse pays you back every time you glance at the dashboard.<\/p>\n
    The trap I fell into with the storage driver<\/h2>\n
    Pulse has two ingest drivers: storage<\/code> (buffers events and flushes them in batches to your main DB) and redis<\/code> (queues events to Redis and flushes via a long-running pulse:work<\/code> worker). I’d assumed I was on storage<\/code>, but a stale PULSE_INGEST_DRIVER=redis<\/code> in our env was sending events through a worker I hadn’t deployed.<\/p>\n
    The symptom: pgbouncer connections climbing during peak hours, and Pulse data showing up half the time.<\/p>\n
    The fix:<\/p>\n
    \/\/ config\/pulse.php\n'ingest' => [\n    'driver' => env('PULSE_INGEST_DRIVER', 'storage'),\n    'trim' => [\n        'lottery' => [1, 1000],\n        'keep' => '7 days',\n    ],\n],\n<\/code><\/pre>\n
    What I’d do differently:<\/p>\n