Docs Pricing Blog

Logging Laravel Errors with Sentry

Sentry + Laravel

Today we’re announcing native integration with Laravel through our new sentry-laravel package. This is a drastic improvement over our previous support (via Monolog) as it ensures proper stacktraces, minimal configuration, and expanded features (such as application detection).

Getting Started

We’ve made it even easier to get started with Laravel on Sentry.

Install the sentry/sentry-laravel package:

$ composer require sentry/sentry-laravel

Add the Sentry service provider and facade in config/app.php:

'providers' => array(
    // ...

'aliases' => array(
    // ...
    'Sentry' => Sentry\SentryLaravel\SentryFacade::class,

Add Sentry reporting to App/Exceptions/Handler.php:

public function report(Exception $e)

Create the Sentry configuration file (config/sentry.php):

$ php artisan vendor:publish --provider="Sentry\SentryLaravel\SentryLaravelServiceProvider"

From here, just toss the SENTRY_DSN in your .env file, or configure things via the config/sentry.php configuration.

Learn More

Take a look at the sentry-laravel project on GitHub to learn more about how things are implemented, as well as additional details on using it with Sentry.

If you’re not yet a Sentry user, you can try Sentry free for 14 days. If that’s not your cup of tea, it’s all open source on GitHub.

Introducing User Feedback

Years back it was common place to be using a desktop app, have it crash, and then be prompted for feedback. It’s not as prevalent as it used to be, but you’ll still find that the best desktop software still does this. Take for example Firefox:

Firefox Crash Dialog

If you manage to trigger a crash, you’ll be presented with a feedback dialog. Typically this form is optional, and the developers will still collect a basic crash report regardless of whether it is filled, but getting any extra helpful feedback can be crucial in determining the root cause of an issue.

Today we’re bringing back classic crash dialogs, and we’re bringing it to the Internet.

Knowing Your Customers

As engineers its pretty easy to get lost in the data. We see an error has happened 100 times, but we don’t really make a strong connection to the user, or realize the frustration they might be feeling. At Sentry we think its important – and vital – to the success of a product that all members of the product team have a level of interaction with customers. This not only creates a better relationship between your team and your customers, but it provides valuable feedback proactively.

User Feedback

Imagine if you were going through the checkout process on, just to be slammed with a big “Internal Server Error” on checkout. What would you do? I’d likely refresh the page a few times, but eventually if it doesn’t start working I’m going to give up and go make my purchase somewhere else. With Sentry it’s always been important for us to ensure you can know who the user is, but with User Feedback we’re bringing that connection even closer by allowing the customer to communicate and provide insight to your product team.

Getting Started

If you don’t already have a Sentry account, start there. Once done, head to your project’s settings, and navigate to the User Feedback section under Data. While actual setup is going to vary for your application, most server-side code is super quick to get up and running. In short, you’re going to hook into your global error handler, often the component that renders your 500.html page. For example, in Django it’s extremely simple to wire up:

<!-- Include the Sentry JS SDK for embedding user feedback -->
<!-- Sentry JS SDK 2.1.+ required -->
<script src=""></script>

{% if %}
  <!-- Show the user the feedback dialog -->
    eventId: '{{ }}',

    // use the public DSN (dont include your secret!)
    dsn: ''
{% endif %}

Now when the page loads, and a Sentry Event ID is available, the user will be prompted with a simple feedback modal:

Sentry Dialog

As long as you have access to the event ID – which most SDKs expose automatically – it’s super quick to get up and running. You’ll find additional instructions as well as the required DSN in your project’s settings.

More details are available in our docs.

Looking Forward

We’re still in the early stages of this feature. There’s already some great ideas floating around to improve upon the concept, but we wanted to get this out in front of people. To us this is a game changer when it comes to interacting with your customers, and just like with our near-realtime error notifications, our goal is to help you tighten that support loop.

Take it for a spin and let us know what you think!

Welcome James Cunningham

We’re excited to announce that James Cunningham is joining the engineering team.

James joins us from Urban Airship where he made phones beep incessantly. He will be working on all of the infrastructure projects that will make Sentry more resilient and easier to operate. In his free time he likes to listen to all the music ever made, argue about sports and videogames, and work in a community garden.

Welcome Jess MacQueen

We’re excited to announce that Jess MacQueen is joining the engineering team.

Jess joins us from Chartio where she worked on everything from building out the UI of their data pipeline to implementing their Google and SAML authentication. In her free time she enjoys running, reading, trying to teach herself the ukelele, and reading.

Important change to our email delivery

Ensuring our users get email notifications of errors in real-time is a top priority for us. Last week, our email provider Mandrill announced significant changes to their service, prompting us to change outbound email providers. While we are doing everything possible to mitigate effects, for our customers, this means that starting Wednesday, there’s a higher chance your Sentry notifications end up in spam.

To prevent this, we strongly encourage you to whitelist Sentry emails. The easiest way to do this is by adding to your contacts. You can also create filters/rules to ensure Sentry email is never marked as spam — we’ve collected instructions for some of the most common providers below.

If you’re curious on the details, spam filtering works by building up a “sender reputation” around the IP address of the server. When we switch providers, we’re also forced to change our IP address, resetting our reputation. We’ll be gradually warming up our new IP addresses over 6 weeks by splitting traffic between our old and new email providers, before cutting over completely. We apologize for any inconvenience and if you have any questions, definitely reach out and ask!

The IP’s we will be sending out from for now are the following if you want to whitelist them. They are also included in our SPF record.