Laravel Sentry Laravel Package

Getting Started

This package wires the Sentry PHP SDK into Laravel so exceptions and log entries are reported to a Sentry project without hand-writing a client. It predates (and is superseded by) sentry/sentry-laravel, so treat it as a legacy integration you inherit rather than one you reach for greenfield.

Minimal setup:

1. Install with Composer: composer require rcrowe/laravel-sentry. Because the package is old (Laravel 4/5 era, illuminate/support ~4.x–5.x), check the resolved constraint against your framework version before anything else. On modern Laravel this will not install cleanly — that alone is usually the deciding factor.
2. Add the service provider to app/config/app.php (providers array) or let package discovery handle it on the Laravel 5 versions it supports: Rcrowe\Sentry\SentryServiceProvider.
3. Optionally register the facade alias ('Sentry' => Rcrowe\Sentry\Facades\Sentry::class) if the package’s facade is not auto-aliased.
4. Publish the config (php artisan config:publish rcrowe/laravel-sentry on L4, vendor:publish on L5) and set the DSN, typically from .env:

// app/config/packages/rcrowe/laravel-sentry/config.php (L4)
// or config/sentry.php (L5)
return [
    'dsn'   => getenv('SENTRY_DSN'),
    'level' => 'error', // minimum log level forwarded
];

Where to look first: the config file (what actually gets sent), then the service provider (what it binds into the container and which Laravel error/log hooks it registers), then the facade (the public surface you'll call).

First use case: prove the pipe works. Trigger a deliberate exception in a staging environment and confirm it lands in Sentry with a readable stack trace and the right environment/release tags. Do this before wiring anything into App::error or the log stack — otherwise you cannot tell a broken DSN from a broken handler.

Implementation Patterns

Catch-and-report at boundaries. The most reliable pattern with this package is explicit capture at application boundaries (controllers, queued jobs, console commands) rather than relying solely on global hooks:

try {
    $this->chargeCard($order);
} catch (\Exception $e) {
    Sentry::captureException($e);
    throw $e; // keep Laravel's normal handling intact
}

This keeps reporting intentional and avoids sending every NotFoundHttpException and validation failure to Sentry.

Wire the global error handler once. For uncaught exceptions, hook Laravel's error handler instead of repeating try/catch everywhere:

// L4: app/start/global.php or a service provider boot()
App::error(function (\Exception $e, $code) {
    if (App::environment('production')) {
        Sentry::captureException($e);
    }
});

Guard by environment — reporting every exception from local dev is the fastest way to make Sentry useless.

Use the log handler for breadcrumbs, not spam. This package’s differentiator is routing Log::error()/Log::critical() calls into Sentry. Keep the threshold at error and let info/debug stay in your normal log channel. This gives you a single Log::error($message, ['context' => ...]) call that both writes locally and alerts remotely.

Attach context deliberately. Pass user id, route, tenant, and any correlation id you already have. Sentry without user/tenant context produces alerts you can’t triage:

Sentry::captureException($e, [
    'user' => ['id' => Auth::id()],
    'extra' => ['order_id' => $order->id, 'tenant' => $tenant->slug],
]);

Integrate at the framework seam, not in business logic. Wrap it in your own ErrorReporter interface bound in the container so application code depends on your abstraction, not on rcrowe/laravel-sentry. When you migrate to sentry/sentry-laravel (or drop Sentry), you swap one binding instead of grepping the codebase.

Queue-safe reporting. In queued jobs, report inside failed() or in the job’s catch block so the failure is associated with the job context; otherwise the report arrives detached from the retry/backoff that actually matters.

Gotchas and Tips

• Version compatibility is the real gate. The package targets Laravel 4/5 and old PHP. If composer require resolves to something ancient or conflicts with your framework, stop — use sentry/sentry-laravel, which is actively maintained and supports modern Laravel, framework-agnostic contexts, and performance tracing.
• Facade and namespace names drift between releases. Confirm the actual facade class (Rcrowe\Sentry\Facades\Sentry vs. an alias like Sentry) and config path against the version you installed; older docs and blog posts disagree.
• Silent failure when the DSN is wrong. A misconfigured DSN or an unreachable Sentry host often means nothing is reported and nothing is logged loudly. Verify with a known-good exception after every config change, and check your PHP error log for SDK warnings.
• Never commit the DSN. It's a write credential for your project. Use .env and make sure the published config reads from it rather than hardcoding.
• Duplicate reports. If both the global App::error hook and the log handler fire for the same exception, you'll get doubles in Sentry. Pick one primary path (typically the error hook) and keep the log handler for Log::error() calls you make yourself.
• Noise control. Filter out expected exceptions (auth failures, 404s, ValidationException) before capture. Left unguarded, this integration will happily report everything and mask real regressions.
• Testing. Don't hit Sentry from tests. Stub your own ErrorReporter in the container, or configure a null/no-op client in the testing environment so suite runs stay hermetic and fast.
• Extension points. The service provider binds the Sentry client and log handler in the container — override those bindings (or the published config) to swap transports, add release/environment tags, or inject a breadcrumb stack rather than forking the package.
• Plan the exit. Given the low maintenance signal (small star count, old framework targets), treat this as technical debt: isolate calls behind an interface now so migrating to the official Sentry Laravel package is a contained change later rather than a rewrite.