# 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](https://laravel.com/docs/13.x/telescope) and [Pulse](https://laravel.com/docs/13.x/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:

```php
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`:

```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](/guides/monitor-laravel-scheduler/) 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](https://laravel.com/docs/13.x/telescope#local-only-installation).

## 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](https://laravel.com/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](https://laravel.com/nightwatch/pricing)). Laravel compares it with [Telescope](https://laravel.com/nightwatch/nightwatch-vs-telescope) and [Pulse](https://laravel.com/nightwatch/nightwatch-vs-pulse).
- [Flare](https://flareapp.io): errors, performance and logs for Laravel, PHP and JavaScript, from Spatie.
- [Sentry](https://docs.sentry.io/platforms/php/guides/laravel/): error tracking and tracing, through the `sentry/sentry-laravel` package.
- [Lampwick](/docs/laravel/): 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](/docs/mcp/). 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](/guides/laravel-failed-jobs/). Choosing a hosted tool? The [Nightwatch alternatives](/compare/nightwatch-alternatives/) compare prices and limits.