Laravel Error Logger Laravel Package

Technical Evaluation

Architecture Fit

• Pros:
  • Lightweight and modular, focusing solely on error logging without coupling to broader monitoring systems.
  • Complements Laravel’s built-in error handling by providing structured storage and optional notifications.
  • Supports Laravel Nova integration for UI-based error review, aligning with teams using Nova for admin panels.
  • MIT license enables easy adoption without legal concerns.
• Cons:
  • Manual logging requirement: Unlike packages like Sentry or Laravel’s default App\Exceptions\Handler, this package does not auto-capture exceptions. Requires explicit ErrorLogger::log() calls, increasing boilerplate.
  • Limited context enrichment: No built-in support for request data, user sessions, or stack traces beyond what’s manually passed (e.g., LogError::withContext()).
  • Notification system is basic: Relies on a single ErrorNotificationJob for daily digests, with no support for real-time alerts or multi-channel (e.g., email + Slack) out-of-the-box.

Integration Feasibility

• Laravel Ecosystem Compatibility:
  • Works seamlessly with Laravel 10+ (based on last release date: 2026-04-13).
  • Assumes standard Laravel project structure (e.g., App\Exceptions\Handler.php for manual logging).
  • Nova integration requires justbetter/nova-error-logger (separate package), adding dependency complexity.
• Database Requirements:
  • Publishes a migration for an errors table with fields like message, context (JSON), level, and created_at.
  • Risk: Schema changes may conflict with existing error-tracking tables (e.g., if using Sentry or custom solutions).
• Third-Party Dependencies:
  • Minimal (e.g., Laravel’s scheduler, notification channels like Slack). No heavyweight libraries.

Technical Risk

• Manual Logging Overhead:
  • Risk: Developers may forget to log errors manually, leading to incomplete data.
  • Mitigation: Enforce logging in App\Exceptions\Handler::render() or via middleware (e.g., LogErrorMiddleware).
• Notification Channel Hardcoding:
  • Risk: Limited flexibility in notification channels (e.g., no PagerDuty, Opsgenie, or custom webhooks).
  • Mitigation: Extend ErrorNotificationJob or use Laravel’s event system to broadcast errors elsewhere.
• Performance Impact:
  • Risk: High-volume errors could bloat the errors table, impacting query performance.
  • Mitigation: Leverage the laravel-error-logger:prune command and archive old data (e.g., to cold storage).
• Nova Dependency:
  • Risk: Adds complexity if the team doesn’t use Nova; UI features are gated behind an additional package.

Key Questions

1. Why manual logging?
   • Does the team need automatic exception capture (e.g., for unhandled errors), or is manual logging sufficient for tracked/known failure paths?
2. Notification Strategy:
   • Are daily digests adequate, or are real-time alerts (e.g., Slack webhooks on critical errors) required?
3. Existing Error Tracking:
   • Does the project already use a tool (Sentry, Bugsnag, etc.)? If so, how will this package complement or replace it?
4. Data Retention:
   • What’s the expected lifecycle of error logs (e.g., 30 days vs. indefinite)? The prune command must align with this.
5. Context Enrichment:
   • Are additional metadata fields (e.g., user ID, request IP, trace IDs) needed beyond the package’s context JSON?

Integration Approach

Stack Fit

• Best For:
  • Laravel monoliths or microservices where manual error tracking is preferred over auto-instrumentation.
  • Teams using Laravel Nova for admin interfaces and wanting a native error dashboard.
  • Projects needing lightweight, self-hosted error logging without external SaaS dependencies.
• Less Ideal For:
  • Teams requiring real-time error monitoring (e.g., production incident response).
  • Projects already using Sentry/Bugsnag (this package lacks features like release tracking or performance metrics).
  • Headless APIs or non-Laravel backends (though PHP compatibility is high).

Migration Path

1. Assessment Phase:
   • Audit existing error handling (e.g., App\Exceptions\Handler, custom loggers).
   • Define scope: Will this replace existing logging, or run in parallel?
2. Setup:
   • Publish config and run migrations:

     php artisan vendor:publish --provider="JustBetter\ErrorLogger\ServiceProvider"
     php artisan migrate
     

   • Configure .env for notification channels (e.g., LARAVEL_ERROR_NOTIFICATION_CHANNEL=slack).
3. Logging Integration:
   • Option A: Modify App\Exceptions\Handler::render() to log exceptions:

     public function render($request, Throwable $exception)
     {
         ErrorLogger::log($exception)->withContext(['user_id' => auth()->id()]);
         return parent::render($request, $exception);
     }
     

   • Option B: Create middleware to log errors for specific routes:

     public function handle($request, Closure $next)
     {
         try {
             return $next($request);
         } catch (Throwable $e) {
             ErrorLogger::log($e);
             throw $e;
         }
     }
     

4. Notification (Optional):
   • Schedule the daily job in App\Console\Kernel.php:

     $schedule->job(ErrorNotificationJob::class)->dailyAt('09:00');
     

   • Configure Slack/other channels via .env or service provider bindings.
5. Nova Integration (Optional):
   • Install justbetter/nova-error-logger and publish its assets if using Nova.

Compatibility

• Laravel Versions: Tested with Laravel 10+ (check composer.json for exact requirements).
• PHP Versions: Requires PHP 8.1+ (verify with php -v).
• Database: Supports MySQL, PostgreSQL, SQLite (standard Laravel DB support).
• Notification Channels: Extendable via Laravel’s notification system (e.g., add mail, discord channels).

Sequencing

1. Phase 1: Core logging setup (migrations, config, manual logging).
2. Phase 2: Notification system (if needed) with Slack/email channels.
3. Phase 3: Nova integration (if using Nova).
4. Phase 4: Pruning strategy (e.g., automate laravel-error-logger:prune via cron).

Operational Impact

Maintenance

• Pros:
  • Self-hosted: No vendor lock-in; data remains in your database.
  • Lightweight: Minimal overhead compared to SaaS tools like Sentry.
  • Extensible: Customize notifications, logging logic, or Nova views via events/observers.
• Cons:
  • Manual Logging Discipline: Requires developer buy-in to log errors consistently.
  • Schema Management: Future migrations may need adjustments if the errors table schema evolves.
  • Notification Reliability: Daily digests depend on Laravel’s scheduler uptime (e.g., missed runs if the server restarts).

Support

• Documentation: Basic but functional (README, CHANGELOG). Limited community support (3 stars, niche use case).
• Debugging:
  • Logs are stored in the errors table; query with:

    SELECT * FROM errors ORDER BY created_at DESC LIMIT 100;
    

  • Nova UI (if enabled) provides a filtered view.
• Vendor Support: MIT license means no official support; issues must be community-driven or self-resolved.

Scaling

• Performance:
  • Write Scaling: Manual logging adds minimal overhead. Batch inserts (e.g., using Laravel’s DB::insert) can optimize bulk operations.
  • Read Scaling: Queries on the errors table may slow with >100K entries. Index created_at and level fields:

    Schema::table('errors', function (Blueprint $table) {
        $table->index('created_at');
        $table->index('level');
    });
    

  - **Archiving**: Use the prune command or archive old logs to a separate table/DB.
  

• Horizontal Scaling: Stateless design means it scales with Laravel’s horizontal scaling (e.g., queue workers for notifications).

Failure Modes