Telescope and Pulse in production, and when to use a hosted tool

Telescope records single requests, Pulse aggregates. Both run in production with a gate, filters and pruning, but neither alerts you when something breaks.

Updated View as Markdown

Telescope records individual requests, queries, jobs and exceptions so you can inspect one; Pulse aggregates them into a dashboard of slow routes, slow jobs and busy users. Both can run in production if you gate the dashboard and limit and prune the data, but neither sends an alert.

We make Lampwick, one of the hosted tools listed at the end. The Laravel parts follow the Telescope and Pulse docs for Laravel 13.x, read 8 Nov 2026.

What each one is for

TelescopePulse
Question it answersWhat happened in this one request or job?What is slow or busy across the app?
RecordsRequests, exceptions, logs, queries, jobs, mail, notifications, cache, scheduled tasks, dumps and more, each as an entryAggregates: slow requests, jobs, queries and outgoing requests (over 1,000 ms by default), exceptions, queue throughput, cache hits, active users, server CPU, memory and disk
Stored intelescope_entries in your databasePulse tables in MySQL, MariaDB or PostgreSQL, with Redis ingest as an option
KeptUntil you prune it7 days by default, trimmed automatically
Dashboard/telescope/pulse

The Laravel docs present Telescope as a companion for local development, and point from Pulse to Telescope for debugging individual events.

Running Telescope in production

Gate the dashboard

The dashboard is open only in the local environment. In other environments, the viewTelescope gate in app/Providers/TelescopeServiceProvider.php decides who gets in:

use App\Models\User;
use Illuminate\Support\Facades\Gate;

protected function gate(): void
{
    Gate::define('viewTelescope', function (User $user) {
        return in_array($user->email, [
            'you@example.com',
        ]);
    });
}

Set APP_ENV=production in production. With APP_ENV=local the dashboard is public, and with it request headers, sessions and query bindings.

Record less

Outside local, the default filter closure records only reportable exceptions, failed jobs, scheduled tasks, slow queries and entries with monitored tags. Keep it. If you widen it, turn off unneeded watchers in config/telescope.php and keep hideSensitiveRequestDetails(). TELESCOPE_ENABLED=false stops recording without removing the package.

Prune every day

telescope_entries grows quickly. Schedule pruning in routes/console.php:

use Illuminate\Support\Facades\Schedule;

Schedule::command('telescope:prune --hours=48')->daily();

Without --hours, entries older than 24 hours go. If the scheduler stops, the table keeps growing; the scheduler guide shows how to check it.

Or keep it local only

Install it with --dev, register it only in local and add it to dont-discover: the local-only steps.

Running Pulse in production

Pulse is built for production: it pre-aggregates data into time buckets. What to set:

  • Gate /pulse with the viewPulse gate in AppServiceProvider; by default it is only open locally.
  • For high traffic, a separate database: PULSE_DB_CONNECTION=pulse (MySQL, MariaDB or PostgreSQL).
  • Ingest through Redis with PULSE_INGEST_DRIVER=redis and a php artisan pulse:work process, which moves entries from a Redis stream into the database. Use a different Redis connection than your queue.
  • Sample busy recorders: a rate of 0.1 records about 10% of entries and scales the numbers up, marked ~.
  • Run pulse:check under Supervisor on each server for the Servers card, and pulse:restart on deploy.

If Pulse can't write, say because its database is down, it fails silently so your app keeps working, and a broken Pulse looks like a quiet week. Log those errors with Pulse::handleExceptionsUsing().

When they are enough, and when they aren't

They are enough for one app on one or two servers, when someone opens the dashboards often and nobody needs to know within minutes.

Neither tells anyone at 23:00 that checkout is throwing or the backup didn't run, and their data lives in your own database, so an outage takes the dashboards down too. A hosted tool keeps the data outside your app, groups exceptions into issues and alerts you. Options for Laravel, checked 8 Nov 2026:

  • Laravel Nightwatch: monitoring from the Laravel team for requests, jobs, queries, exceptions, logs and scheduled tasks, with alerts. US and EU data centers, 14 to 90 days of history by plan, free to start (pricing). Laravel compares it with Telescope and Pulse.
  • Flare: errors, performance and logs for Laravel, PHP and JavaScript, from Spatie.
  • Sentry: error tracking and tracing, through the sentry/sentry-laravel package.
  • Lampwick: issues, requests, jobs, queries, logs and schedule health from the Laravel package, plus uptime, SSL, domain and DNS checks, status pages and an MCP server. Alerts by iOS push, email, Slack, Discord, Microsoft Teams or webhooks.

Pulse can stay next to any of them, and Telescope on your laptop.

Next step

If the gap is alerts on failed jobs and missed tasks, start with why Laravel jobs fail and how to find out. Choosing a hosted tool? The Nightwatch alternatives compare prices and limits.