Laravel Nightwatch is the first monitoring product where the Laravel team itself decided what a Laravel app should report, and it shows. Requests, queued jobs, scheduled tasks, queries, exceptions, and outgoing HTTP calls arrive correlated out of the box, with none of the "now instrument your framework" homework that Datadog or New Relic hand you. The setup takes about ten minutes.
But there is a structural detail buried in that setup which cost me an afternoon: Nightwatch depends on a persistent agent process, and that single fact decides whether you can use it at all. My own production site runs on shared hosting, and I found the hard boundary by hitting it. This guide covers the clean install first, then the part the marketing page does not mention.
What Nightwatch Actually Is
Nightwatch is Laravel's first-party application monitoring service. Your app does not send telemetry directly to Nightwatch's servers. Instead, the package hands events to a lightweight local agent (a sidecar process you run with Artisan) which buffers them and ships batches upstream every few seconds or when the buffer fills. That architecture is why request overhead stays low: your HTTP request writes to a local socket and moves on, and the agent does the slow network work out of band.
Three consequences of that design are worth internalizing before you install anything:
- The agent is a long-running process. It has to be running for any data to reach the dashboard. No agent, no telemetry — silently.
- You need somewhere for that process to live. A VPS with Supervisor or systemd, Laravel Forge, or Laravel Cloud (where it is managed for you) all work.
- If your host cannot keep a process alive, Nightwatch is off the table. More on that below, because that was my situation.
Step 1: Install the Package
composer require laravel/nightwatch
Sign up at nightwatch.laravel.com, create your application and an environment (production, staging), and Nightwatch issues an environment-specific token. The token is per environment, not per app; keep production and staging separate so staging load tests never pollute your production baselines.
Step 2: Configure the Environment
Add the token to .env:
NIGHTWATCH_TOKEN=your-environment-token
Two optional variables are worth setting on day one:
LOG_CHANNEL=nightwatch
NIGHTWATCH_REQUEST_SAMPLE_RATE=0.1
Routing the log channel through Nightwatch puts your application logs in the same timeline as requests and exceptions, which is where they become useful. The sample rate is the knob most people discover too late: at 1.0 every request is recorded, and on a site doing real traffic you will burn through your event allowance fast. Sampling at 10 percent still gives you statistically honest latency percentiles. Exceptions are what you want at full fidelity; request traces are what you sample.
And because this is an environment change on a production box: if you cache config (you should), the new values do not exist until you run php artisan config:cache again. I have been bitten by that exact gotcha on this site — an .env edit that silently did nothing for a day because the cached config still held the old values.
Step 3: Run the Agent
php artisan nightwatch:agent
Run that in a terminal, load a few pages, and events appear in the dashboard within seconds. That is the happy-path demo. It is not a production setup, because the moment your SSH session dies, so does the agent.
In production the agent belongs under a process monitor. On a VPS, a Supervisor program definition is the standard answer:
[program:nightwatch-agent]
command=php /var/www/your-app/artisan nightwatch:agent
autostart=true
autorestart=true
user=www-data
stopwaitsecs=10
This is the same pattern you already use for queue workers: if you have Horizon or queue:work under Supervisor, the agent is just one more program block beside them. I walked through the full Supervisor setup, including the log and restart settings that matter, in my guide to running Laravel queues under Supervisor on Amazon Linux; everything there applies verbatim to the Nightwatch agent.
On Laravel Cloud the agent is built into the platform and there is nothing to run. On Forge, provision it as a daemon.
Step 4: Generate Some Truth
Trigger real activity: browse the app, dispatch a queued job, let the scheduler tick. Then look at what Nightwatch correlates for free — the thing that impressed me most on first contact. A slow request shows its queries. A failing scheduled task shows its exception. An outgoing HTTP call that took four seconds shows up attached to the request that made it, not floating in a separate "external services" tab you would never think to open.
The Part Nobody Tells You: Shared Hosting Is a Hard No
Here is the first-hand discovery, and if you searched for "Nightwatch shared hosting," this is your answer: it does not work, and it cannot be made to work honestly.
This site — the one you are reading — runs on Hostinger shared hosting. It deploys through a GitHub Actions pipeline that rsyncs on push to main, and its scheduler runs off a cron entry. There is no Supervisor, no systemd access, and the platform's process management exists specifically to kill long-running user processes. That is not Hostinger being hostile; it is what shared hosting is — the economics only work if nobody parks a daemon on the box.
I tried the obvious workarounds so you do not have to:
- Cron-starting the agent every minute. You get a pile of overlapping agent processes, then the host's limits reap them mid-buffer. Telemetry arrives in random gaps that are worse than no telemetry, because you think you are monitored.
nohupfrom an SSH session. Survives minutes to hours, dies unpredictably. Same false-confidence problem.
The failure mode is the dangerous part. Nightwatch does not error when the agent is gone — events just quietly stop flowing. A monitoring tool that silently stops monitoring is strictly worse than knowing you are blind.
So the honest decision tree: if you are on a VPS, Forge, or Laravel Cloud, install Nightwatch today; it is the best signal-per-minute-of-setup in the Laravel ecosystem right now. If you are on shared hosting, either accept a different toolkit or treat this as one more input to the "is it time to move to a VPS" decision I laid out in optimizing Laravel on shared hosting.
What I Run Instead on Shared Hosting
Since I cannot run the agent, my monitoring on this site is assembled from parts that survive the shared-hosting constraint — and it covers a surprising amount of what Nightwatch would:
- Exception visibility through Laravel's log files, reviewed on a schedule instead of streamed. Boring, effective.
- A scheduler heartbeat. A cron entry on shared hosting can silently vanish; mine did, this June, and queued mail piled up for days before I noticed. Now a scheduled task writes a timestamp I check externally; if the timestamp goes stale, the cron is dead. That one check would have saved me the whole outage.
- Uptime and response-time checks from outside: an external pinger tells you the truth about what visitors experience, which no in-process agent can.
- Query discipline enforced before deploy, not observed after. Without live query tracing, N+1 problems have to be caught in development; my N+1 detection workflow is how I keep them from reaching a box where I would never see them.
That stack is objectively worse than Nightwatch. It is also the honest ceiling of the platform, and knowing your ceiling beats pretending you do not have one.
Tuning Nightwatch Once It Runs
For readers on infrastructure that supports it, three practices from the broader monitoring trenches, applied to Nightwatch specifically:
Alert on deviation, not existence. An exception occurring is not an incident; an exception rate change is. Wire alerts to thresholds that represent behavior shifts, or you will train yourself to ignore the channel within two weeks, and an ignored alert channel is a disabled one with extra steps.
Watch queue lag before queue failures. Jobs that fail are loud. Jobs that quietly take nine minutes instead of nine seconds are the ones that become a user-facing incident later. The queued-job timing view is where slow rot shows first.
Review weekly, not just reactively. Fifteen minutes once a week scanning slowest endpoints and noisiest exceptions turns monitoring from an alarm system into a roadmap. Most of my performance backlog comes from exactly this kind of scan, not from incidents.
The Bottom Line
Nightwatch earns its place: first-party correlation of requests, jobs, queries, and exceptions with a ten-minute setup — if your infrastructure can keep one Artisan process alive. That "if" is the entire decision, and it is the sentence I wish someone had written before I spent an afternoon proving it against a shared-hosting process reaper.
Check your process-management reality first. Then install.
The expensive version of this mistake is discovering mid-incident that your monitoring stopped reporting weeks ago — the exact shape of the dead cron that let my own queued mail pile up for days. Auditing a Laravel app's monitoring and hosting reality, including the "should this still be on shared hosting" call, is work I take on through my services.
