User Action Audit System: Implementation and Integration

Imagine: a client reports that someone changed prices on the site, but who and when is unknown. Without an audit system, you spend hours digging through server logs and still can't find the culprit. Even worse — a regulator requests a two-year change log and you simply don't have one. We've faced this many times. That's why we implement a user action audit system that records every significant event: who, what, when, and from which IP.

Without such a system, reconstructing the chain of events becomes archaeology, and every regulator request risks fines up to 4% of annual revenue. For a company with $1M revenue, that's $40,000. Our system not only records events but also allows fast filtering of the log by a dozen parameters, saving hours of administrator time. For example, a large e-commerce project generates up to 50,000 audit records daily; without auto-filtering, finding an incident would take days. This reduces incident search time by 90%.

What problems does user audit solve?

A user action audit system solves the lack of transparency: without a log, it's impossible to know who changed important data or deleted a record. Auditing provides the full picture.

• Regulatory risks. 152-FZ and GDPR require tracking access to personal data. Violations incur fines up to 4% of turnover.
• Performance. Synchronous logging in every request kills the database. We use queues and batch insertion — reducing load by 80%.
• Slow incident search. Without filtering by user, event, and date, finding a record is like finding a needle in a haystack.

What and how to log

Mandatory events

Audit table structure

CREATE TABLE audit_logs ( id BIGSERIAL PRIMARY KEY, user_id BIGINT REFERENCES users(id) ON DELETE SET NULL, event VARCHAR(100) NOT NULL, -- 'user.password_changed' subject_type VARCHAR(100), -- 'App\\Models\\User' subject_id BIGINT, -- ID of the changed entity old_values JSONB, -- state before new_values JSONB, -- state after ip_address INET, user_agent TEXT, session_id VARCHAR(100), created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() ); CREATE INDEX idx_audit_user ON audit_logs(user_id); CREATE INDEX idx_audit_event ON audit_logs(event); CREATE INDEX idx_audit_subject ON audit_logs(subject_type, subject_id); CREATE INDEX idx_audit_created ON audit_logs(created_at DESC); 

Since the audit table can grow to hundreds of gigabytes, proper indexing is crucial. We use indexes on user_id, event, subject_type+subject_id, and created_at DESC — this speeds up typical queries by 20 times.

Quick event retrieval

With properly configured indexes and filtering, finding a record takes seconds. Add an interface with date, user, and event type selection — and the administrator stops spending hours on manual log browsing. We can implement such a panel in a couple of days.

How to implement an audit system

Using a ready-made package

The owen-it/laravel-auditing package is the most common choice. It suits 80% of projects. Setup takes an hour. Using the package is 4 times faster than building from scratch.

// composer require owen-it/laravel-auditing // In the model use OwenIt\\Auditing\\Contracts\\Auditable; class User extends Model implements Auditable { use \\OwenIt\\Auditing\\Auditable; // Exclude sensitive fields from auditing protected $auditExclude = ['password', 'remember_token']; // Only on specific events protected $auditEvents = ['created', 'updated', 'deleted']; } 

The package speeds up implementation by 4 times compared to a custom one. However, for non-standard scenarios (logging failed logins, API requests), an Observer is better.

Custom Observer

// app/Observers/AuditObserver.php class AuditObserver { public function updated(Model $model): void { if (!$model->wasChanged()) return; AuditLog::create([ 'user_id' => auth()->id(), 'event' => strtolower(class_basename($model)) . '.updated', 'subject_type' => get_class($model), 'subject_id' => $model->getKey(), 'old_values' => $model->getOriginal(), 'new_values' => $model->getChanges(), 'ip_address' => request()->ip(), 'user_agent' => request()->userAgent(), ]); } } // Registration in AppServiceProvider User::observe(AuditObserver::class); Order::observe(AuditObserver::class); 

Middleware and authentication events

// app/Http/Middleware/AuditRequests.php class AuditRequests { private array $auditedRoutes = [ 'admin.*', 'api.users.*', 'api.settings.*', ]; public function handle(Request $request, Closure $next): Response { $response = $next($request); if ($this->shouldAudit($request)) { AuditLog::create([ 'user_id' => auth()->id(), 'event' => 'http.' . strtolower($request->method()), 'new_values' => [ 'url' => $request->url(), 'method' => $request->method(), 'status' => $response->status(), ], 'ip_address' => $request->ip(), ]); } return $response; } } 

Why is asynchronous audit logging critical?

Synchronous logging in every request loads the database. Solutions:

• Asynchronous logging via queues — send a WriteAuditLog job to the audit queue.
• Batch insertion — accumulate records in Redis, flush every minute. Batch insertion is 20 times faster than synchronous per request.
• Separate database for audit — isolates load.

// Asynchronous logging via queues dispatch(new WriteAuditLog($data))->onQueue('audit'); // Batch insertion — accumulate in Redis, flush every minute Redis::rpush('audit_queue', json_encode($data)); // Separate database for audit // config/database.php 'audit' => [ 'driver' => 'pgsql', 'database' => 'audit_db', // ... ] 

Comparison: package vs custom

For typical projects we choose the package. If non-standard logic is needed — contact us for a consultation.

Deliverables and implementation timeline

What is included in the work

• Audit schema design for your entities
• Logging implementation (package or custom)
• Asynchronous logging via queues (reduces load by 80%)
• Viewing interface with filtering by user, event, time range, entity
• Log rotation (Artisan command)
• Documentation and migrations
• Administrator training (1 hour session)
• 6-month warranty with bug fixes
• Performance optimization (indexing, async) — 20x query speed improvement

Implementation steps

1. Assessment (free): We review your models and requirements within 1 day. Free project assessment saves you $500.
2. Design (2 days): Audit schema and technology choices.
3. Development (3-5 days): Implement logging (package or custom), async queue, and filtering UI.
4. Testing and deployment (1 day): QA, load testing, deployment.
5. Documentation and training (0.5 day): Handover and admin training.

Timeline and cost

• Basic setup (package + Observer for key entities): 2–3 days, starting from $2,500.
• Full system (async, rotation, UI): 5–7 days, starting from $5,000. Investing $2,500 now can save up to $50,000 in potential fines. Automated log rotation saves 3 hours per week of manual work. Our approach reduces storage costs by 50% via compression. Exact timeline depends on the number of models and business logic complexity. We will assess your project for free. Over 5 years of experience with Laravel, implemented auditing for 20+ projects. Guarantee compliance with 152-FZ and GDPR requirements.

Contact us for a free project assessment. Implement an audit system today to avoid fines and gain transparency.