Are your emails actually sending? Monitoring Laravel mail
Laravel mail monitoring catches silent failures — the password resets and receipts that never arrive. Get visibility into every send and failure.
Here's a question that should make you nervous: how would you know if your app stopped sending email? Not the dramatic, exception-throwing kind of broken — the quiet kind. The SMTP credentials that expired. The provider that started silently dropping messages. The queued notification that failed three times and gave up. Laravel mail monitoring exists because email failures are almost never loud. Your code runs, the job completes, no error surfaces — and a customer never gets their password reset, their receipt, or their shipping confirmation. You find out days later, from a support ticket, when the damage is done. Let's fix that blind spot.
Why mail fails silently
Email is mostly fire-and-forget. You call Mail::to($user)->send(...), often from a queued job, and move on. If the mail driver hiccups, the failure happens far from the user-facing request that triggered it. Common silent killers:
- Expired or rotated API keys for your mail provider.
- A provider rate-limiting or suspending your account.
- Queued mailables failing and exhausting their retries.
- A bad template variable throwing only for certain users.
None of these print a red banner. They just mean the email didn't go.
What to watch
Good mail monitoring answers three questions at a glance:
- Did sends drop? A sudden fall in volume is as telling as a spike in errors.
- Which mailables are failing? Group by notification type so "order confirmations" is one issue, not noise.
- Where did it break? The job, the recipient context, and the exception — without logging real email addresses you shouldn't.
Wiring it up with Lookout
Lookout includes a mail watcher and a queue watcher, so you get visibility into both the send and the job behind it. Install from your Laravel app root:
composer require lookout/tracing
php artisan lookout:install
Configure the connection with plain env values:
LOOKOUT_LARAVEL=true
LOOKOUT_API_KEY=your-project-api-key
LOOKOUT_URL=https://your-lookout-host.example.com
The provider is auto-discovered. Failed mailables and the queued jobs that run them surface as grouped issues, so a broken template or a dead provider shows up as one clear signal instead of scattered log lines you'll never read.
Alert before the support ticket
Visibility is only useful if it reaches you in time. Add an alert rule on a threshold over a 1h or 24h window, routed to Email or Slack. If failed notifications cross the line, you hear about it once — not per message. The goal is simple: you learn the password-reset emails stopped before the first frustrated customer does.
Don't forget the quiet metric
Errors tell you what broke; volume tells you what stopped. A provider can accept your messages and still drop them downstream, throwing no error at all. Watching send volume alongside failures catches that class of problem — the one where everything "works" and nothing arrives.
Email is often the most important thing your app does that you never look at. Make it visible, alert on it, and you close one of the most expensive blind spots in any web app. Spin up a free Lookout project — 10,000 events a month, one project, no credit card — and the next time a mail provider quietly fails, you'll be the first to know instead of the last.