Forem: Dan

Setting Up Error Monitoring in Laravel Without the Overhead

Dan — Wed, 25 Feb 2026 19:19:52 +0000

It's 2:17am and someone on X (man I miss it being Twitter) is telling me my app is broken.

Not how it's broken, mind you. Just a screenshot of a white page and "hey your thing is dead lol". So now I'm SSH'd into a server, running tail -f storage/logs/laravel.log, scrolling through thousands of lines of interleaved garbage — deprecation warnings I've been ignoring for months, some debug output I forgot to remove, and somewhere in there, presumably, the actual error that's causing a 500 for this person. I find it eventually. A null pointer on a relationship I forgot to eager load. Fifteen minutes of log archaeology for something that would've taken two seconds if I'd had any kind of monitoring set up.

This was like three years ago. I'd love to tell you I fixed it the next day. I didn't.

The `Log::error()` era

Here's what I did instead, and I suspect you've done the same thing. I sprinkled Log::error() calls in strategic places. I set up a Slack webhook that fired on 500 responses. I told myself this was monitoring.

And honestly? It kind of works. For a while.

The problem is that Log::error('Something went wrong', ['user' => $user->id]) gives you exactly one data point. You know that it happened. You don't know how often. You don't know what the request body looked like, or what the user was doing before the error, or whether this is the same bug you saw last Tuesday or a new one. Every error is an island. There's no grouping, no trends, no context.

I had a bug once that was happening about 40 times a day. I didn't know that. My Slack channel showed me "500 error on /dashboard" and I'd think ah, that one again, I'll fix it this week. Turns out "that one" was actually three different bugs hitting the same route, affecting different users in different ways. I only found out when I finally sat down and grep'd through a week's worth of logs. Fun afternoon.

The Sentry question

Look, Sentry is good software. I'm not going to pretend otherwise.

But when I looked at adding it to a Laravel side project — one with maybe 100 active users — something felt off. The SDK pulls in a fair amount. The dashboard is built for teams running microservices at scale, and half the features I'd be paying for (performance monitoring, session replay, release tracking) are things I genuinely don't need. The pricing tiers assume you're a startup burning through venture capital, not someone running a $29/month Digital Ocean droplet.

I wanted Laravel exception monitoring that felt like it belonged in a Laravel app. Not a platform-agnostic tool with a Laravel adapter bolted on. Something where the setup was measured in minutes, not in "follow this 12-step configuration guide and don't forget to publish the config file and set up the queue driver and..."

So I built one. (This is the part where I'm supposed to be casual about the self-promotion, but honestly, I built it because I needed it, and I think you might need it too.)

Actually setting it up

Two steps for PHP errors:

composer require oopsy/oopsy-laravel

Then add your DSN to .env:

OOPSY_DSN=http://oops-xxx@oopsy.dev/api/v1/projects/1

That's it. No publishing config files, no middleware to register, no service provider to add manually. The package auto-discovers and registers itself. When an exception happens in your app, it captures the full stack trace with code context, the request data, user information, environment — and sends it asynchronously using Laravel's Http::async(). Your response times don't change. The monitored app never slows down, and it never crashes because of the monitoring itself (which, hm, would be ironic).

For JavaScript errors — and this is the bit I'm probably most pleased with — you add a single script tag:

<script src="https://your-oopsy.dev/api/v1/js/oopsy_pub_xxx.js"></script>

No npm install. No build step. No 200KB bundle imported into your frontend pipeline. It's a self-contained script served per-project that captures uncaught exceptions, unhandled promise rejections, and records breadcrumbs: click events, console errors, XHR and fetch requests, navigation changes. It uses sendBeacon for delivery, which means errors get reported even when the user is closing the tab. The whole thing is maybe a few kilobytes.

I spent an embarrassing amount of time getting that breadcrumb recording right, actually. There's this edge case with fetch where you need to monkey-patch the global but also not break anyone else's monkey-patching, and — anyway, that's a different blog post.

What shows up on the other end

When an error comes in, it gets fingerprinted and grouped automatically. So if 500 users hit the same null pointer exception, you see one issue with an event count of 500, not 500 separate entries you have to mentally deduplicate. The fingerprinting works off the exception class, the file, and the line number — first in-app frame, not vendor code — which means it groups things the way you'd actually think about them.

Each issue shows you the full stack trace with surrounding code, the HTTP request that triggered it, which user was affected, severity level, and environment. JavaScript errors get a little JS badge so you can immediately tell whether something is blowing up server-side or in the browser. You can filter by status (unresolved, resolved, ignored), severity, source, environment.

There are email and Telegram alerts too. Because what good is Laravel exception monitoring if it doesn't wake you up at 2am? (I'm joking. Set your notification schedule. Please.)

The money part

Free tier is 1,000 errors per month on one project with 7-day retention. For a side project, that's probably more than enough — and if you're getting more than 1,000 errors a month on a side project, you might have bigger problems than monitoring. Hobby tier is $5/month for 50,000 errors across 5 projects with 30-day retention, which is where most small production apps land. There's a Pro tier at $19/month if you need more, but I'm not going to sell you on it here.

The thing I specifically didn't want was the kind of pricing where you look at your error volume and think maybe I should just suppress some of these. Laravel exception monitoring should make you want to see every error, not dread the invoice.

Anyway

I don't have a neat conclusion for you. Error monitoring is one of those things that feels optional right up until the moment it isn't, and then you're reading log files at 2am in your pants wondering why you didn't set something up six months ago. I've been that person. More than once.

Two lines of config. That's the whole pitch, really.

Dan

I Built an Error Tracker Because Sentry Made Me Feel Poor

Dan — Mon, 23 Feb 2026 15:05:40 +0000

I was just a Laravel dev who wanted to know when his app broke. The pricing pages said no. So I built my own error tracker.

I was three clicks deep into Sentry's pricing page when I did the maths on what monitoring my side project would actually cost. The side project that makes, on a good month, enough to cover its own hosting. Forty bucks a month to watch for errors on an app that serves maybe two hundred people.

I closed the tab.

Tried Flare. Nicer for Laravel, sure. Still felt like I was paying enterprise rent on a studio flat. Nightwatch? Same energy. Every single one of these tools is built for a team with a Jira board and a VP of Engineering and a budget that doesn't make someone physically wince. I'm just a bloke with a Laravel app and a DigitalOcean droplet. I only need to know when something breaks.

That's it. That's the whole requirement. When a thing goes wrong, tell me about it. Maybe group the errors so I'm not drowning in five hundred copies of the same stack trace. Maybe send me a Telegram message so I notice before my users do. The bar is, honestly, not that high.

So of course — of course — my brain did the thing. You know the thing. The thing where you're a developer and you look at a problem and instead of paying someone to solve it, you think: I could build this.

This is almost always a terrible idea. I know this. You know this. We all know this. And yet.

I opened a blank Laravel project on a Tuesday evening. Told myself I'd just prototype the ingestion endpoint. See if I could catch an exception from another Laravel app and store it. Two hours, tops, then I'd come to my senses and just pay for Flare.

That was months ago.

The thing I built is called Oopsy, and it's a proper laravel error monitoring tool now, which still surprises me a bit. TALL stack — Tailwind, Alpine, Livewire, Laravel - because that's what I know and I wasn't about to learn React for this. Domain-driven design because the codebase started getting messy around week three and I needed to impose some order before I lost my mind.

Here's what it actually does. On the PHP side, you run composer require on a small Laravel package. It hooks into the exception handler, captures the stack trace with code context, grabs request and user info, collects breadcrumbs from your logs and queries, then fires it off asynchronously. Your app doesn't slow down, doesn't crash if Oopsy is unreachable. It just quietly reports what went wrong.

The bit I'm weirdly proud of is the JavaScript error catching. You add a single script tag. That's it. No npm install, no build step, no configuration file with forty options. The script captures uncaught exceptions, unhandled promise rejections, parses stack traces across Chrome, Firefox, and Safari (which all format them differently, because browsers hate us), records breadcrumbs of what the user clicked and what network requests happened, then sends everything via sendBeacon so it doesn't block the page unload. I spent an embarrassing amount of time getting sendBeacon to work without CORS preflight requests. The trick is sending as text/plain. Anyway.

Errors get grouped by fingerprint — a hash of the exception class, the file, and the line number from the first non-vendor stack frame. So when your PaymentController throws the same StripeException forty times in an hour, you see one issue with a count of forty, not forty separate issues cluttering up your dashboard. You can filter by severity, by environment, by whether it came from PHP or JavaScript. You can mark things resolved, and if they come back, they automatically flip to regressed.

It's laravel error monitoring without the complexity tax. That was the whole point.

Then came the pricing question, which felt strange from the other side. I'd started this project because pricing annoyed me, and now I had to set prices myself.

I kept it simple. Free tier gives you a thousand errors a month, one project, seven days of retention. For most hobby projects, that's probably enough. For five dollars a month — the Hobby plan — you get fifty thousand errors, five projects, thirty days. And if you're running something more serious, nineteen dollars a month gets you half a million errors, unlimited projects, ninety days of retention, unlimited team members.

I don't know if those numbers are right. I genuinely don't. Maybe the free tier is too generous and I'll bleed money on infrastructure. Maybe the Pro tier is too cheap and I'm leaving money on the table. But I kept coming back to the feeling I had on that Sentry pricing page — that sinking this isn't for people like me feeling — and I figured I'd rather err on the side of affordable.

(There's a joke in there about erring on the side of errors. I'm choosing not to make it. You're welcome.)

The honest bit, the bit I almost didn't write: I have no idea if this works as a business. The economics of running a laravel error monitoring SaaS are not straightforward. You're ingesting potentially huge volumes of data, storing stack traces and breadcrumbs, running background jobs to process and group everything. The free tier users generate real costs. Hosting isn't free. My time isn't free, even though I keep pretending it is.

But it works as a tool. I use it on my own projects. When something breaks at 2am, my phone buzzes with a Telegram message that tells me exactly what happened, which file, which line, what the user was doing. I fix it in the morning. Nobody writes me an angry email.

And look, maybe that's enough for now. Not everything has to be a venture-scale business. Sometimes you build a thing because the existing options made you feel like you couldn't afford to be a professional developer, and you think other people might feel that way too. Sometimes the "I could build this" impulse, against all odds, produces something that actually works and that you're actually a little bit proud of.

Sometimes the terrible idea turns out fine.

Oopsy is at oopsy.dev if you want to poke at it. Free tier, no credit card, takes about two minutes to set up. If you're doing laravel error monitoring on a budget — or just on principle — maybe it's useful to you. Maybe it's not. I'm not going to pretend I've solved monitoring forever.

I just wanted to know when my app broke.

Dan