Laravel Application Monitoring: What to Track and Why

Nobody finds out until someone rings on Wednesday to ask where their order confirmation went. That gap, between what your monitoring watches and what your business depends on, is where the expensive failures live.

The failures nothing is watching

Laravel's documentation is explicit about how queues behave. A job is attempted once by default. You raise that with the --tries option on queue:work or the Tries attribute on the job class, and the Backoff attribute sets the delay between attempts.

Once those attempts are exhausted, an asynchronous job is considered failed and inserted into the failed_jobs table. Nothing retries it automatically. Somebody has to notice the row and run queue:retry.

The queue:work command is a long-lived process that stores the booted application state in memory, which is why the docs tell you to restart workers during every deployment.

They also tell you to run the process under a monitor such as Supervisor "to ensure that the queue worker does not stop running". Without a process monitor, a worker that dies stays dead and jobs accumulate behind it.

The scheduler has the same shape of problem. On a conventional server, the docs call for a single cron entry running schedule:run every minute. Rebuild that server, move the PHP binary or lose a file permission and the entry stops firing.

Every scheduled task stops with it: backups, renewals, reminders, cleanup. The cron line in the documentation ends >> /dev/null 2>&1, so output is discarded by default.

The framework supplies the hooks to close that gap. onFailure() and emailOutputOnFailure() fire when a task exits non-zero, and pingOnSuccess() and pingOnFailure() will call a URL either way, which is what an external heartbeat check listens for. They are opt-in, and most applications never turn them on.

Two more blind spots sit beyond that. Outbound integrations fail on the far side of the wire, so a payment gateway or email API can start rejecting requests while your application returns a cheerful 200 to every visitor.

Business outcomes are the last backstop. A deploy that breaks checkout leaves every infrastructure metric healthy while orders per hour fall to zero.

An uptime check confirms your server answered the phone. It tells you nothing about whether anyone inside is doing the work.

What to track, and in what order

Three published frameworks converge on the same advice. Google's Site Reliability Engineering book (2016) names four golden signals: latency, traffic, errors and saturation. Tom Wilkie's RED method narrows that to rate, errors and duration for request-driven services. Brendan Gregg's USE method covers resources: utilisation, saturation and errors.

The common thread is that you alert on symptoms a user would feel, rather than on every cause that might produce one.

For a Laravel application earning real money, the priority order runs roughly like this. Failed job count and queue backlog depth first, because that is where silent failure concentrates. Then a scheduler heartbeat, so you know the cron is alive rather than assuming it.

Then request error rate and latency percentiles, measured separately for successful and failed requests, since the SRE book points out that a fast HTTP 500 will otherwise flatter your latency numbers.

Then outbound integration errors, and one business metric that maps to money, usually checkout or sign-up success.

Formal service level objectives sit below that line for most small applications. The SRE Workbook defines an error budget as "100% minus the SLO" and presents it as a tool for balancing reliability against other engineering work. That trade-off only bites where there is enough competing work to prioritise.

What the first-party tools actually do

The most common Telescope question is whether to run it in production. The documentation is specific about its purpose: Telescope "makes a wonderful companion to your local Laravel development environment", and the dashboard is restricted to the local environment by default.

It is not barred from production. The default filter published in the docs records reportable exceptions, failed jobs, scheduled tasks, slow queries and monitored tags in non-local environments, and access there runs through the viewTelescope gate. The docs also note that APP_ENV must be set to production, "otherwise, your Telescope installation will be publicly available".

What Telescope gives you is a detailed record of individual events for debugging. It does not aggregate over time or notify anyone, which is the job the rest of the stack does.

Horizon covers the queue layer, free and open source, for applications whose queue runs on Redis. The docs describe it as a dashboard and code-driven configuration that monitors "job throughput, runtime, and job failures".

Horizon also ships the alerting most teams assume they have to buy. Horizon::routeSlackNotificationsTo(), routeSmsNotificationsTo() and routeMailNotificationsTo() send a notification when a queue's wait time crosses a threshold set per connection and queue in config/horizon.php, defaulting to 60 seconds. Configuring that one array is the cheapest queue alerting available to a Laravel application.

Pulse covers aggregate health. The docs describe it as delivering "at-a-glance insights into your application's performance and usage", tracking "bottlenecks like slow jobs and endpoints". It is a dashboard, which means going and looking.

Nightwatch is Laravel's hosted option, and the only first-party monitoring product that costs anything. Telescope, Horizon and Pulse are all free. Its pricing page lists a free tier at 300,000 events a month with 14 days of lookback, and Pro at US$20 a month for 7.5 million events with 30 days. An event there counts each request, outgoing request, query, job, notification, mail, command, cache operation and scheduled task, so event volume climbs a great deal faster than request volume.

Alongside the first-party tools sit the established error trackers with Laravel packages, including Sentry, Flare and Honeybadger. Sentry's published pricing runs a free Developer tier at 5,000 errors a month for one user, with Team at US$26 a month on annual billing.

All vendor pricing above was checked in September 2026 and excludes VAT. For one application, a stack of Horizon, Pulse, an external heartbeat check and a single paid error tracker sits inside the free tiers or in the low tens of dollars a month.

Alerts that nobody reads

Instrumenting everything and paging on all of it produces a worse outcome than monitoring less. The clearest evidence comes from healthcare, where the effect has been studied properly.

A cross-sectional study of 3,986 nurses across 213 US hospitals, published in BMJ Open Quality in 2023, found that 83% reported feeling overwhelmed by alarms at least occasionally, and 55% had at least occasionally encountered a situation where a patient needed urgent attention and nobody responded to the alarm.

The setting is different and the mechanism is the same: alerts that mostly do not require action stop being read. Google's SRE book makes the corresponding argument for paging, that black-box monitoring has "the key benefit of forcing discipline to only nag a human when a problem is both already ongoing and contributing to real symptoms". Everything below that threshold files a ticket.

No tool answers the last question. An alert at three in the morning needs somebody contracted to pick it up.

What the market actually commits to

Monitoring is usually described rather than specified. The prevailing language across support and maintenance retainers is "proactive monitoring", "24/7" and "peace of mind", with thresholds and response times left open. Managed hosting tends to be more precise, though what it covers is the server rather than the application running on it.

Certification is no guide either. The five Cyber Essentials controls are firewalls, secure configuration, user access control, malware protection and security update management, and monitoring is not among them.

We publish where monitoring sits in our own Laravel support retainers. Plans start at £450+VAT a month for 6 hours with next-business-day response, proactive uptime monitoring begins at £750+VAT alongside same-day response for urgent issues, and £1,250+VAT covers 20 hours with a 4-hour response on anything critical.

Two limits are worth stating plainly. We respond during UK business hours rather than around the clock, and we are not an enterprise network operations centre.

Building new monitoring infrastructure from scratch is project work rather than maintenance, which is a line we hold deliberately and explain before anyone signs.

Most applications we take over arrive with no instrumentation at all, and the first month of a retainer is largely spent finding out what has been failing quietly. If you are unsure which category yours falls into, the warning signs are straightforward to check yourself before you talk to anyone.