Download the PHP package codebar-ag/laravel-event-logs without Composer

Laravel Event Logs

This package records HTTP requests and model lifecycle events as rows in your database. Configure a dedicated database connection for the event_logs table so logging stays isolated from your primary application data.

Table of Contents

• Requirements
• Installation
• Configuration
  • Database Connection
  • Schema Management
  • Configuration reference
• Upgrading
• Usage
  • Middleware Request Logging
  • Model Event Logging
  • Adding Context

Requirements

• Laravel 13+
• PHP 8.3+
• A database connection for event logs (can be your default connection, but a separate connection is recommended)

Installation

Composer Install

Publish Configuration

This publishes config/laravel-event-logs.php and config/laravel-event-logs-exclude-routes-defaults.php (Nova/Livewire route skip list). Override exclude_routes in the main config file if you need a custom list; you can delete the defaults file from your app if you inline the array.

Publish Migrations (Optional)

If you want to customize the migrations or need them in your application's database/migrations directory, you can publish them:

Note: Migrations are automatically loaded from the package, so publishing is optional. However, if you plan to use the event-logs:schema:create command, it's recommended to publish the migrations first, or the command will automatically publish them for you.

Configuration

Database Connection

By default, the package uses your application's default database connection. You can specify a custom database connection for event logs by setting the connection option in your configuration file:

Or via environment variable:

This is useful when you want to store event logs in a separate database for better performance or isolation.

When enabled is true, EventLog::isEnabled() also requires connection to be a non-empty string. Set EVENT_LOGS_CONNECTION (or the config value) to your connection name; use your app’s default connection name explicitly if you do not use a dedicated logs connection.

Schema Management

The package provides Artisan commands to manage the event logs database schema:

Create Schema

Create the database schema for event logs:

This command will:

• Check if the event logs connection is configured
• Exit successfully if the event_logs table already exists
• Publish package migrations to database/migrations/ if needed
• Run php artisan migrate for the single package migration (2026_04_10_000000_create_event_logs_table.php), creating the full table (including response_status, duration_ms, and string subject_id) in one step
• Fail with Artisan output if migrate returns a non-zero exit code

Note: The command requires the connection configuration to be set. Migrations are published into your app so the path is under the application root (required by Laravel’s migrator).

Update Schema

Reconcile the live event_logs table with the package definition (columns and indexes in order). Use this when the table already exists but may be missing columns (for example after a partial manual setup or an old install):

This command will:

• Require the event logs connection configuration (same as create/drop)
• Create the full event_logs table if it is missing (same layout as the package migration)
• Otherwise add any missing columns, then try to convert legacy integer subject_id to string(36) when detected, then ensure indexes (duplicate index errors are ignored)
• Print what changed, or Schema is already up to date. when nothing was needed

Converting subject_id on MySQL, PostgreSQL, or SQL Server often needs doctrine/dbal; the package lists it under composer suggest. For apps that only use Laravel’s migration history on a clean database, php artisan migrate is usually enough.

Drop Schema

Drop the database schema for event logs:

Or with the force option (no confirmation):

This command will:

• Check if the event logs connection is configured
• Verify if the schema exists
• Drop the event_logs table if it exists

Warning: This will permanently delete all event logs data. Use with caution.

Configuration reference

Published defaults live in config/laravel-event-logs.php. Common keys (see the file for the full list and inline comments):

Upgrading

The package ships one migration: database/migrations/2026_04_10_000000_create_event_logs_table.php. It creates event_logs with the full current schema (HTTP metrics columns, string subject_id, no Azure-era sync columns). If the table already exists, up() does nothing (safe when upgrading).

If you previously published older package migrations (2025_08_09_*, 2026_04_07_*, 2026_04_08_*), remove those files from your app’s database/migrations and publish again (or copy the new migration only) so you do not duplicate create_event_logs migrations.

HTTP middleware must remain a terminable middleware in the stack (Laravel invokes terminate() automatically when registered via append / the HTTP kernel). If you only call handle() in custom tests, call terminate($request, $response) yourself.

Breaking changes (recent versions)

• Azure Event Hubs and EventLogTransport were removed; logs are stored only in the database.
• EventLog::toProviderPayload(), legacy_to_array_provider_payload, and Azure-shaped toArray() are removed; use normal Eloquent toArray() / API resources as needed.
• exclude_routes_match defaults to auto so shipped exclude_routes prefix entries (e.g. nova.) work. Set EVENT_LOGS_EXCLUDE_ROUTES_MATCH=exact if you only list full route names.

Usage

Middleware Request Logging

The EventLogMiddleware automatically logs all HTTP requests after the response is available. Add it to your application:

Configuration

Implementation

Logged Data

The middleware logs these HTTP request details:

• Request Information: Method, URL, route name, IP address
• Response: HTTP status code and duration in milliseconds
• Request User: Authenticated user type and ID (see user_resolution in config)
• Request Data: Sanitized headers and payload
• Context: Filtered application context (context.* config: allowlist, max keys, max JSON bytes)

Optional: set persist_mode to queued and configure queue.connection / queue.queue to write rows via RecordEventLogJob.

Example Output

Model Event Logging

Use the HasEventLogTrait to automatically log model events (created, updated, deleted, restored). Rows are written through the same EventLogRecorder as HTTP logs, so persist_mode (sync or queued) applies here too.

Implementation

Logged Data

The trait automatically logs these events:

• created: When a model is created
• updated: When a model is updated
• deleted: When a model is deleted
• restored: When a soft-deleted model is restored (if using SoftDeletes)

Each model event logs:

• Event type (created, updated, deleted, restored)
• Model class and ID
• User who triggered the event
• Model attributes (for created events)
• Changes made (for updated events)
• Original values (for updated events)
• Dirty keys (for updated events)
• Context information

Example Output

Adding Context

Use Laravel’s Context facade to add data that can be persisted on event_logs rows. What actually gets stored is filtered by the context config (enabled, optional allow_keys, max_keys, max_json_bytes) — see Configuration reference.

For example, set context in middleware that runs before EventLogMiddleware:

Register the context middleware before EventLogMiddleware: