Laravel Activitylog Laravel Package

Product Decisions This Supports

• Build vs. buy for the audit trail. This answers a recurring "do we build our own change history?" question with a near-zero-cost yes to buying. MIT-licensed, 5.9k stars, maintained by Spatie with a documented upgrade path, it removes an entire epic (schema, model events, diffing, causer/subject relations, retention command) from the roadmap and lets the team spend that capacity on differentiators.
• Feature scoping for "who changed what." Enables customer-facing activity feeds, per-record history panels, and admin "recent activity" dashboards without new backend design work — performedOn() / causedBy() / withProperties() map directly to the UI stories PMs typically write ("show who edited this and when").
• Compliance-adjacent roadmap items. Model event logging plus attribute_changes (old vs. new values) covers the common "we need a record of changes to customer records" requirement from security questionnaires and SOC 2 / GDPR readiness conversations — enough to answer the question, not enough to claim certified audit-grade logging.
• Support and CS tooling. The Activity model makes "what did this user actually do before they filed this ticket?" a queryable question, which shortens investigation time and reduces engineering escalations from support.
• Change-failure triage. Because activity rows are linked to causers and subjects, incident post-mortems can reconstruct the sequence of writes rather than guessing from application logs.
• Cheap experiment for "activity" as a product surface. Multiple named logs, batching, and custom properties let you ship a scoped v1 (e.g., only billing records) and expand coverage based on usage instead of committing to full-app instrumentation up front.
• Roadmap constraint to record explicitly: this is a data layer, not a product. There is no UI. Budget design/engineering for the viewer surface or the feature is invisible to customers.

When to Consider This Package

Adopt when most of these are true:

• The stack is Laravel 11+ / PHP 8.4+ (v5 line). Older stacks must pin the 4.x line and accept a slower upgrade cadence — verify the supported matrix before committing, since the v5 release intentionally dropped older runtimes.
• You need record-level change history on Eloquent models (create/update/delete) plus ad-hoc domain events, and you want it in the database — queryable, joinable to users, and reportable — rather than in log files.
• The requirement is internal visibility, support, and dispute resolution, not regulated evidence retention.
• You can absorb one migration and one table and are willing to own retention (a cleanup command exists; the policy does not).
• Your primary keys are integers or you are prepared to edit the published migration for UUID/ULID before the first migrate. This is the single most common first-day mistake.
• You want no vendor relationship, no seat pricing, no procurement — MIT, self-hosted, no data leaves your infrastructure.

Look elsewhere (or build) when:

• You need tamper-evident, append-only, cryptographically verifiable logs, or formal audit certification. This table is writable by the app and by anyone with DB access; treat it as operational history, not evidence.
• You need a turnkey audit UI, alerting, or SIEM integration — this is storage plus a fluent API only.
• Write volume is very high. Every logged event is an insert plus JSON serialization. At scale, model-event logging on hot tables needs deliberate decisions (which events, queued writes, sampling) and a partitioning/archival plan, or the table becomes the largest thing in the database.
• PII handling is strict. Properties and attribute diffs will happily store personal data; erasure requests then require custom redaction work. If you cannot govern what gets captured, this creates compliance debt faster than it resolves it.
• Multi-tenant isolation is a hard requirement — there is no built-in tenant scoping; you will add it yourself in queries and policies, and a missed scope is a data leak.
• You are not on Laravel, or you need cross-service/cross-language logging.

How to Pitch It (Stakeholders)

To executives: We can deliver "who changed what, and when" — a feature customers ask for in security reviews and a tool support needs daily — for roughly the cost of one migration and a few days of integration. It is MIT-licensed, self-hosted, has no per-seat or subscription cost, and is backed by a well-known PHP vendor with 5.9k GitHub stars, published docs, a changelog, and a maintained release line. The build alternative is a multi-week epic we would have to staff and maintain forever. Recommend approval as a contained, reversible bet: it adds one table and no external dependency, and it can be removed without touching business logic.

To engineering: Low-risk, idiomatic Laravel. Add LogsActivity to the models you care about, publish and adjust the migration for our key format (we use UUIDs — fix subject_id/causer_id before the first migrate), and get model-event diffs, causer/subject relations, named logs, batching, and a cleanup command out of the box. Two real engineering obligations: decide retention and archival on day one, and bound what gets logged (which events, which attributes, how much PII) so we don't turn the activity table into an accidental copy of the customer database. Also treat the audit log as a product with a consumer — someone has to build the viewer.

Ask: Approve the dependency and a timeboxed spike on two or three high-value models, with an explicit retention policy and a PII allowlist as exit criteria. Reassess coverage after 30 days of real data.