Originally published at hafiz.dev
Three official monitoring tools. Same team. Zero clear explanation of when to use which one. If you've ever stared at the Laravel docs and thought "okay but which one do I actually need?" You're not alone. This is the post that should have existed when Nightwatch launched.
The short version: Telescope is for local development debugging, Pulse is for high-level production metrics, and Nightwatch is for full production observability. But that framing alone doesn't help you make a decision. So let's go deeper.
What Each Tool Is Actually Solving
These three tools exist because monitoring is not a single problem. It's three separate problems that happen to sit next to each other:
During local development, you need to know what your app is doing right now as you build it. You want to see every query, every job, every mail, every notification fired by that last request, in full detail.
In production, you need two very different things depending on what's going wrong. When you want a health check ("is anything trending badly?"), you need aggregated metrics. When something has already gone wrong and a user is affected, you need the full story of exactly what happened, in what order, and to whom.
That's three different needs. Telescope solves the first. Pulse solves the second. Nightwatch solves the third.
Laravel Telescope: Your Local Debugging Companion
Telescope is the most mature of the three. It's been in the Laravel ecosystem since 2018 and is free open source. Install it as a dev dependency, visit /telescope in your browser, and you get a detailed log of everything happening in your app.
Install it with composer require laravel/telescope --dev, then run php artisan telescope:install and php artisan migrate. Every request, Eloquent query, job dispatch, mail, notification, event, cache operation, and exception shows up in a clean dashboard with the exact SQL, the stack trace, and the timing.
The thing Telescope does that nothing else does: it shows you the full context of a single request. You can see that GET /dashboard fired 47 queries, took 340ms, dispatched 2 jobs, and fired 6 events, all in one view, with every detail drillable.
The hard rule on Telescope: never run it in production. It stores every request to your database, which creates serious performance overhead and a potential privacy liability. The official recommendation is to gate it behind an environment check. In AppServiceProvider, check App::isLocal() before registering Telescope. Or simply require it with --dev and it won't be available in production at all.
Telescope is free. It's the right tool for local development, staging debugging, and CI troubleshooting. It's the wrong tool for production.
Laravel Pulse: The Production Health Dashboard
Pulse is newer (it shipped with Laravel 11) and sits at the opposite end of the spectrum from Telescope. Where Telescope is granular and detailed, Pulse is aggregated and high-level. It's built for the "is my app healthy right now?" question.
Install it with composer require laravel/pulse, then run php artisan pulse:install and php artisan migrate. Visit /pulse and you'll see a dashboard showing CPU usage, memory, slow queries, slow routes, failed jobs, queue depth, and cache hit rates, all as aggregated metrics over a configurable time window.
Pulse is free open source and runs inside your own infrastructure with zero external dependencies. Everything is stored in your own database. There's no external service, no SaaS account, no event quota. You own all the data.
The limitation is what "aggregated" means in practice. Pulse will tell you that /api/orders has a P95 response time of 800ms over the last hour. It won't tell you which specific request hit 2,400ms, which user triggered it, what queries ran during that request, or how those queries relate to each other. It gives you the trend. It doesn't give you the incident.
Pulse also requires php artisan pulse:work running as a daemon to process its queue. This is a lightweight process, but it's something to account for in your Supervisor configuration. Alternatively you can use the inline driver for lower-traffic applications that don't need the separate daemon.
Pulse is the right tool for a free production health dashboard when you want to spot trends and anomalies at a glance. It's the wrong tool when you need to investigate a specific incident.
Laravel Nightwatch: Full Production Observability
Nightwatch launched in June 2025 and fills the gap that Telescope and Pulse don't cover: you know something is wrong in production, and you need to understand exactly what happened.
Where Pulse shows you aggregates, Nightwatch keeps every individual event. Where Telescope only works locally, Nightwatch is designed specifically for production. It connects the dots between the request, the user, the queries, the jobs, the exceptions, and the timeline, all in one view.
Install the package with composer require laravel/nightwatch. Add your NIGHTWATCH_TOKEN to .env. Then start the agent:
php artisan nightwatch:agent
The agent runs as a sidecar process, buffering events locally and sending them to Nightwatch's servers roughly every 10 seconds. The overhead is minimal, under 3ms per request per the official documentation. On Forge, the agent setup is a one-click daemon. On Cloud, it runs automatically.
What Nightwatch tracks out of the box, with no configuration: HTTP requests with full timing and user context, exceptions with stack traces and affected user counts, Eloquent queries with their source, queue jobs with execution time and retry history, outgoing HTTP requests, mail, notifications, scheduled tasks, cache operations, and Artisan commands.
The pricing structure: the free plan covers 200,000 events per month, no limits on apps or environments, with 14-day reporting. The Pro plan starts at $20/month for 5M events, 30-day reporting, and unlimited seats. There are Team and Business tiers for higher volumes.
The key difference from Pulse in practice: when a user reports that their checkout timed out at 11:47pm last Tuesday, Nightwatch can show you exactly that request. The route, the user, the 14 queries it ran, which one took 1,800ms, the job it dispatched, whether that job succeeded. Pulse can show you that Tuesday night had elevated P95 response times. That's the difference between a metric and an answer.
One architectural note: Nightwatch requires the sidecar agent to be running continuously. On serverless deployments like Laravel Vapor, you'll need a separate VM to run the agent. This isn't a dealbreaker, but it's something to plan for.
How to Pick the Right Tool
The decision tree is simpler than it looks:
A few real-world scenarios to make this concrete:
Solo developer, side project, no budget: Install Telescope for local development. Add Pulse to production. You get free debugging locally and a free health dashboard in production. You'll be flying blind during incidents, but for a low-traffic side project that's an acceptable trade-off.
Small team, SaaS product with paying customers: Add Nightwatch on the free plan. 200k events per month is enough for most early-stage SaaS applications, especially with sampling enabled. The moment a customer reports an issue, you'll have the data to investigate it. This is where "free but I'll get it wrong" becomes "I found the bug before the customer gave up."
Established product with meaningful traffic: Run all three. Telescope locally, Pulse for the quick health dashboard, Nightwatch for incident investigation and production debugging. They're complementary, not competing. The Nightwatch free plan covers a surprisingly large amount of traffic if you set sampling to 10-20% on high-volume endpoints.
Can You Use All Three Together?
Yes, and the official guidance confirms it. Laravel will continue supporting Telescope and Pulse regardless of Nightwatch's growth. The tools overlap only superficially. Their actual use cases are distinct enough that running all three makes sense for any production application you care about.
The practical setup for a team running all three:
Telescope is a dev dependency, so it only exists locally and in staging. Pulse and Nightwatch both live in production. Pulse runs php artisan pulse:work as a supervised daemon for metric aggregation. Nightwatch runs php artisan nightwatch:agent as a supervised daemon for event collection. The two agents don't interfere with each other.
One thing to do immediately if you add Nightwatch: disable it in your test environment. Add NIGHTWATCH_ENABLED=false to your phpunit.xml or test .env. You don't want test runs burning through your event quota.
| Telescope | Pulse | Nightwatch | |
|---|---|---|---|
| Cost | Free (open source) | Free (open source) | Free plan + from $20/mo (Pro) |
| Environment | Local / staging only | Production-safe | Production-safe |
| Installation | Composer package | Composer package | Composer package + cloud account |
| What it tracks | Every request, query, job, mail, notification, dump | Aggregated metrics: slow queries, CPU, queue depth, cache | Individual requests, exceptions, jobs, queries, outgoing HTTP, scheduler |
| Data granularity | Individual request-level detail | Sampled aggregates over time windows | Every individual event with full context |
| Alerting | None | None | Yes: Slack, Linear, webhooks |
| Self-hosted vs cloud | Self-hosted | Self-hosted | Cloud (SaaS) |
| Best for | Debugging during development | Production health dashboard | Investigating production incidents |
Setting Up Nightwatch on Laravel Forge (The Quickest Path)
If you're on Forge, Nightwatch has a one-click integration. In your Forge site settings, find the Nightwatch section, enter your environment token, and Forge automatically creates the supervisor daemon, restarts it if it crashes, and wires up the environment variables. The whole thing takes about 90 seconds.
For a non-Forge server, add the Supervisor config manually. Create /etc/supervisor/conf.d/nightwatch.conf:
[program:nightwatch]
process_name=%(program_name)s
command=php /var/www/your-app/artisan nightwatch:agent
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stdout_logfile=/var/www/your-app/storage/logs/nightwatch.log
Then run sudo supervisorctl reread && sudo supervisorctl update && sudo supervisorctl start nightwatch.
This is the same pattern you'd use for Horizon or any other long-running Laravel process. If you're already running Horizon for your queues, adding Nightwatch follows the exact same playbook. The Laravel queue jobs guide covers this Supervisor setup in detail if you need a full walkthrough.
Frequently Asked Questions
Is Nightwatch worth it if I'm already using Sentry?
Sentry is excellent at exception tracking specifically. It won't give you slow query data, queue depth, cache miss rates, or scheduler health. Nightwatch gives you the full picture including exceptions. They can run side by side if you want Sentry's issue tracking workflow, but Nightwatch alone covers more ground.
Does Pulse replace Telescope?
No. Pulse is for production metrics. Telescope is for local debugging. They serve completely different purposes and run in different environments.
Can Nightwatch run on shared hosting?
The Nightwatch agent requires a long-running process, which most shared hosts don't support. You need a VPS, a Forge-managed server, Laravel Cloud, or a container environment. If you're on shared hosting, Pulse is your only production monitoring option.
What counts as an "event" in Nightwatch's quota?
Each of these counts as one event: an HTTP request, an outgoing HTTP request, a queue job execution, an Eloquent query, a mail send, a notification dispatch, a scheduled task run, a cache operation, an Artisan command run, and an exception. On a typical request that fires 12 queries, that's 13 events (1 request + 12 queries). Use the sampling configuration to manage quota on high-traffic endpoints.
Should I disable Nightwatch in local development?
You can run it locally with a dedicated development environment in your Nightwatch account, but it will burn through your free quota unnecessarily. Set NIGHTWATCH_ENABLED=false in your local .env and use Telescope locally instead. That's what it's built for.
Nightwatch in Practice: Where It Earns Its Keep
The tools that benefit most from Nightwatch in production are the ones with the most moving parts. If you're running a Laravel REST API with multiple consumers, Nightwatch shows you which endpoints are slow for which users, and which outgoing HTTP calls to third-party services are dragging response times down.
If you're building admin-heavy SaaS applications with Filament, Nightwatch is especially useful. Admin panels tend to run complex Eloquent queries against large datasets, and the N+1 issues that are invisible in development with a handful of records become obvious with real production data. The complete Laravel + Filament SaaS guide covers the kind of query complexity that benefits most from production observability. When you can see in Nightwatch that your Filament resource list is firing 60 queries per page load on a table with 10,000 rows, you know exactly where to add eager loading and which relationship to optimise first.
The most common mistake Laravel developers make with monitoring is treating it as binary: either you have it or you don't. The reality is that Telescope, Pulse, and Nightwatch solve three different problems at three different points in the development lifecycle. Start with Telescope locally. Add Pulse to production for free. Add Nightwatch when you have users who will notice when something breaks.
Building a Laravel app and not sure which of these fits where you are right now? Get in touch and I'm happy to talk through your setup.
Top comments (0)