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.
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
| Telescope | Pulse | |
|---|---|---|
| Question it answers | What happened in this one request or job? | What is slow or busy across the app? |
| Records | Requests, exceptions, logs, queries, jobs, mail, notifications, cache, scheduled tasks, dumps and more, each as an entry | Aggregates: 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 in | telescope_entries in your database | Pulse tables in MySQL, MariaDB or PostgreSQL, with Redis ingest as an option |
| Kept | Until you prune it | 7 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
/pulsewith theviewPulsegate inAppServiceProvider; 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=redisand aphp artisan pulse:workprocess, 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.1records about 10% of entries and scales the numbers up, marked~. - Run
pulse:checkunder Supervisor on each server for the Servers card, andpulse:restarton 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-laravelpackage. - 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.