- What is laravel-admin-ext/reporter used for?
- It adds an error-reporting dashboard to laravel-admin. Exceptions from your Laravel application are stored in a database table and shown in the admin panel with the message, file, line, stack trace, request data, and the authenticated user. It is intended for browsing error history inside an existing admin, not for SQL report building or external alerting.
- How do I install laravel-admin-ext/reporter?
- Install it with Composer using composer require laravel-admin-ext/reporter. Then publish the package config and migrations, run the migrations, and clear Laravel's caches. The package assumes you already have encore/laravel-admin installed and bootstrapped as your back-office.
- Which Laravel versions does laravel-admin-ext/reporter support?
- The last release was in January 2022, so its Composer constraints target older Laravel and laravel-admin majors. Check the package's composer.json against your locked PHP and Laravel versions before adopting it. On newer stacks you may need to pin older dependencies or fork and patch the package.
- How does automatic exception capture work?
- The package hooks into Laravel's exception handling path and writes a row for each captured exception. Each record includes the exception class, message, file, line, stack trace, request parameters, headers, and the authenticated user when available. You review those records in the laravel-admin error list.
- Can I ignore specific exceptions or customize what is recorded?
- Yes, the package ships a publishable configuration file that lets you fine-tune which exceptions are recorded and ignored. Review that config after installation and align it with your application's exception strategy. The available context does not indicate built-in field masking or redaction controls, so add those yourself if needed.
- Is it safe to store request parameters, headers, and stack traces in the database?
- Treat that data as sensitive because exception rows can include credentials, tokens, SQL with bound values, and PII. The viewing surface relies on laravel-admin's authentication, so a misconfigured admin guard or broadly permissioned operator becomes a data-leak path. Limit access, add redaction or retention controls where required, and consider isolating the error table from your primary database connection.
- Does laravel-admin-ext/reporter replace Sentry or Laravel Telescope?
- No. It provides browsable exception history inside laravel-admin, but it does not offer the alerting, deduplication, aggregation, or production monitoring that Sentry, Flare, or Bugsnag provide. Laravel Telescope is aimed at local development introspection rather than long-term error history. Use Reporter as a convenience layer or stopgap, not as a full replacement for an APM or error SaaS.
- How do I mark errors as read or clear the report list?
- The error list includes unread status indicators and supports marking entries as read. You can also bulk clear records to keep the list manageable. Both actions are handled from the laravel-admin report screen.
- What are the production risks of writing exceptions to the primary database?
- Persistence happens inside the exception path, so a database outage, an oversized payload, or a missing table can cause a secondary failure while your application is already degraded. That can amplify an incident instead of just losing telemetry. If you adopt the package, isolate the write path with a separate connection or queue where possible and monitor the error table's growth and retention.
- Is laravel-admin-ext/reporter actively maintained?
- The last release was in early 2022, and the package has thin adoption with no recent activity indicated. laravel-admin itself is also in maintenance or sunset territory compared with Filament and Nova. Assume you will own and patch the code if you adopt it, and avoid it for new projects that are not already committed to laravel-admin.