Error Tracking Tools Compared: Sentry, Flare and Ray Explained

When you compare error tracking tools for a web app, the real choice is usually between Sentry and Flare: both catch errors in production and alert your developer before users start emailing support. Sentry is the safer pick when your product spans several languages or includes a mobile app, while Flare is the sharper fit for Laravel apps. Ray, often mentioned in the same breath, is a desktop debugger your developer runs locally, and it replaces neither.

Ray is one of the tools I use myself, and Ray and Flare are made by the same Belgian company, Spatie, so keep that in mind as you read. Since I'm based in the EU, I've also noted where each tool keeps your data.

The short answer

My rule of thumb: if the app is built in Laravel and the rest is JavaScript, start with Flare. If you have code in several languages, say a native iOS app or a Python service, choose Sentry. Ray isn't an alternative to either. It's something your developer uses alongside them.

Error tracking is one layer of keeping a web app healthy after launch. How it fits with updates, backups and support is covered in my web application maintenance guide.

Error tracking vs logging vs debugging

These terms get mixed up, but they do different jobs, and most production apps need all three.

Error tracking captures exceptions: the moments when code stops because something unexpected happened. The tool groups identical errors, so 300 users hitting the same bug show up as one issue with a counter, and it alerts you the first time a new error appears. Each issue comes with a stack trace (the list of code lines that ran just before the failure), browser and user details, and the steps that led to the error.

Logging is the app's diary. The code writes messages as it works: a payment started, a sync with the accounting system pulled in 40 invoices, a login was rejected. Laravel has this built in, and according to Laravel's logging documentation it can write to files, the system log, Slack and external services. Logs earn their keep when nothing throws an error but something is still wrong, like an email that never went out.

Debugging is what a developer does to find and fix the bug. That's where Ray comes in. Instead of sprinkling temporary print statements through the code and hunting for them in the browser or log files, the developer sends values, database queries and emails to a separate window. That shortens the gap between "I can see the bug" and "it's fixed".

Why catching errors before users report them pays off

Without error tracking, your users are your alerting system. That's a poor alerting system for three reasons.

Plenty of users never report anything. They retry, give up or find a workaround. In a B2B product, that can mean someone at your customer's company loses half an hour a week to the bug, and the frustration builds quietly until renewal time.

When a report does arrive, it's late and vague. "It doesn't work" is a typical message, and your developer then spends billable time working out which page, user and moment it was about.

You also miss patterns. An error that hits a small share of checkouts looks like bad luck from the support inbox. In an error tracker, it's one issue with a number that keeps climbing.

The biggest payoff comes right after a release. With error tracking in place, a developer can see within minutes whether the new version introduced errors and roll back before most users notice. If your users are spread across time zones, an alert also means the error is waiting for a developer the next morning instead of bouncing around support for days.

If the whole app is down, that's a different situation, and I've written a step-by-step plan for when your website or app is down.

Sentry, Flare and Ray up close

Sentry: the broadest coverage

Sentry supports most languages and platforms, from PHP and JavaScript to Python, iOS and Android. If you run a Laravel backend, a Next.js frontend and a mobile app, all three can report to one place, and you can follow an error from the phone all the way to the server-side line that failed.

According to Sentry's pricing page, the Developer plan is free for one user and 5,000 errors a month. The Team plan costs $26 a month billed annually and includes unlimited users and 50,000 errors. Logs are part of every plan, with 5 GB included. Sentry can store your data in Frankfurt, but you pick the region when you create the organization, and it can't be changed later without starting a new one.

The downside is that Sentry does a lot. There are many settings, and the bill grows with the errors, logs and traces you send, so keeping costs predictable takes attention.

Flare: built for Laravel

Flare comes from Spatie, the team behind a long list of widely used Laravel packages, and it shows in the details. Flare has first-class support for queues, jobs and Livewire, and it presents errors in a way that matches how a Laravel app is structured. On the frontend it covers JavaScript, React, Vue and Svelte.

On Flare's pricing page, Hobby starts at $9 a month for 10,000 errors, but only for one project and one user. Standard costs $29 a month for 100,000 errors with unlimited projects and users. Every plan includes error tracking, performance monitoring and logs, data is kept for 30 days, and there's a 10-day free trial with no credit card. Flare offers a data processing agreement.

The downside is scope. If part of your product is written in something other than PHP or JavaScript, that part needs another tool, and at that point consolidating everything in Sentry is usually simpler.

Ray: your developer's tool, not your alarm

Ray is a desktop app for Mac, Windows and Linux. The developer sends values, database queries, emails, events and timing measurements from the code to a separate window. It works with Laravel, plain PHP, JavaScript, Vue, React and WordPress. According to Ray's website, a license costs $49 and is valid for a year, and the free trial shows up to 20 messages per session.

Ray is part of my own toolkit on Laravel projects, and it's especially useful for reproducing an error locally or seeing exactly which database queries a page runs. If the app is slow rather than broken, start with my breakdown of why a web app gets slow.

For you as a client, the point is simple: the faster the developer finds the cause, the fewer hours you pay for. But Ray sees nothing once the app is in your users' hands. It should only be installed as a development dependency, so it never ships to the production server.

Which one fits your setup

Here's how I'd typically choose, based on how the product is built:

Laravel's own Nightwatch can also capture errors and is a genuine option for Laravel apps. I cover it alongside uptime and cron monitoring in my list of web app uptime monitoring tools.

The tool matters less than two decisions around it. First, who gets the alert and what they're expected to do. An error report that lands in an inbox nobody reads is the same as no error report. Second, cutting the noise: known errors that don't matter, errors caused by one user's browser extensions, and anything from staging. Skip that, and everyone learns to ignore the alerts.

When each tool is the wrong choice

Sentry is more than you need for a pure Laravel app run by a small team that just wants errors served up without learning a large product. On a busy app, the bill can also get hard to predict if nobody watches usage.

Flare is the wrong fit if a meaningful part of the product is written in languages other than PHP and JavaScript, or if you have a native mobile app whose crashes need reporting. You'd end up running two tools, which is rarely better than one.

Ray is the wrong choice for monitoring, full stop. It can't see what happens for your users and doesn't send alerts. It isn't essential either: Laravel Debugbar and Telescope are free alternatives, and some developers prefer a classic step debugger. That's your developer's call, not yours.

And the honest part: if you have a simple marketing website with no logins, payments or background jobs, you probably don't need error tracking at all. A free uptime monitor that tells you when the site is down is enough. If another developer already runs your app day to day, they should be the one to set this up, because whoever fixes the errors should own the configuration.

Error reports, personal data and GDPR

An error report can include a user's name, email, IP address and whatever they typed into a form just before the failure. Under GDPR that's personal data, and the tool's vendor becomes your data processor. That applies to EU companies, and generally also to companies outside the EU whose users are in the EU.

• Sign a data processing agreement (DPA) with the vendor before the tool goes live.
• Decide where the data should live. With Sentry, the EU region must be chosen when the organization is created.
• Strip sensitive fields such as passwords, national ID numbers and payment details before they're sent. Both Sentry and Flare have settings for this.
• Set a sensible retention period. Flare keeps data for 30 days, and Sentry keeps 30 days on the free plan and up to 90 days on Team.
• Mention the tool in your privacy policy.

I'm a developer, not a lawyer, so this isn't legal advice. If you handle sensitive data, have a privacy professional review your setup.

Next steps

1. Decide who responds to alerts and how fast. What belongs in that agreement is covered in my software maintenance agreement checklist.
2. Pick the tool that matches your stack: Flare for Laravel and JavaScript, Sentry if you have several languages or a mobile app.
3. Create the account in your company's name and invite the developer as a user.
4. Set it up in both backend and frontend, with staging and production kept separate.
5. Review the errors after two weeks. Silence the noise and fix whatever hits the most users.

If you want one developer who sets up error tracking and also fixes what it finds, here's how I handle ongoing maintenance and development for web apps.

Frequently asked questions

Isn't Laravel's built-in logging enough?+

Only if someone reads the logs regularly. Log files on a server don't alert anyone, they don't group identical errors, and they make it hard to tell whether a bug hit one user or a thousand. For a small internal tool, a log channel that pushes critical errors to Slack can work as a start. Once you have paying customers, a proper error tracker costs less than the time spent digging through log files.

Will an error tracker slow down my app?+

Barely, when it's configured properly. An error report is only sent when an error actually happens. Performance monitoring adds a bit more overhead because it records requests continuously, but you can usually sample a fraction of traffic instead of all of it. If users notice a difference, that's normally a sign the configuration needs tuning, not that the tool has to go.

Can I self-host error tracking instead?+

Yes. Sentry can be self-hosted, which keeps all error data on servers you control and appeals to teams with strict data requirements. The trade-off is another piece of infrastructure to run, with its own updates, storage and backups, and Sentry offers no dedicated support for it. For most small and mid-sized companies, a hosted EU region or a European vendor is less work.

Who should own the Sentry or Flare account?+

Your company. Create the account with a shared company email and a company card, then invite your developer as a user. That way you keep the error history and alert settings if you change developers, the same way you should own your code, domain and hosting. It also makes onboarding a new developer much faster.