Product Decisions This Supports
- Build vs. buy for audit logging. Audit trails are table stakes for compliance conversations (SOC 2, ISO 27001, GDPR access logging, client security questionnaires), but rarely a differentiator. This package lets you buy that capability for the cost of an integration instead of a sprint — freeing roadmap capacity for revenue-facing work. A credible in-house equivalent (DB schema, event capture on Statamic user actions, CP listing UI, filters, CSV export, retention) is realistically 2–4 weeks of engineering plus ongoing maintenance; adoption is closer to 1–3 days.
- Whether to standardize on Statamic for client builds. If you run a Statamic agency practice, "do we have an audit log story?" is a recurring pre-sales question. Having a vetted, MIT-licensed answer makes Statamic a viable platform for regulated-adjacent clients (nonprofits, healthcare marketing sites, public sector microsites) that would otherwise force a move to a heavier CMS.
- Feature scoping for an internal admin/compliance console. The CP UI + analytics + CSV export maps directly to support workflows: "who changed this page and when," "who deleted that entry," "export last quarter's admin activity for the auditor." Use it to decide whether to invest in a homegrown admin console or lean on the CMS's own panel.
- Agency retainer and services packaging. An audit-log deliverable is a clean line item in a support retainer or a "compliance readiness" upsell. Low delivery cost, high perceived value, and it creates a natural reason for recurring maintenance conversations.
- Roadmap deprioritization signal. The package's low adoption (9 stars, 0 dependents) suggests this is a niche need in the Statamic ecosystem, not a market gap worth building a product around. Treat it as an internal enabler, not a commercial bet.
- Incident response and support triage decisions. System logs alongside user audit logs shorten the "what happened before the site broke" loop and reduce MTTR on content-related incidents.
When to Consider This Package
Adopt when:
- You are already on Statamic (verify the supported major versions against your install before committing) and the need is internal visibility and evidence, not forensic-grade security.
- You need a defensible audit trail for a security questionnaire, a client contract, or an internal policy — with exportable CSV your auditor or compliance owner can actually consume.
- You want CP-native UX so non-technical editors and content admins can self-serve "who changed this" without filing a ticket to engineering.
- Your volume is modest (single-site, tens of admin users, thousands of events per month) and database storage is acceptable.
- You have the appetite to vendor a small, single-maintainer MIT package and can pin the version.
Look elsewhere when:
- You need tamper-evident or immutable logs (hash chaining, append-only/WORM storage, signed exports). A plain DB table an admin can
DELETE FROM will not satisfy a serious auditor, and this package does not claim to.
- You need SIEM forwarding, alerting, or long-term retention off-box — pair with or replace by shipping events to Datadog, Sumo, or an S3 archive; or use
spatie/laravel-activitylog plus your own pipeline if you want a wider Laravel ecosystem and larger maintainer base.
- You need enterprise-grade reliability: 0 dependents and a single maintainer is a real bus-factor risk. If the audit log is a contractual control, budget for a fork you own, or build.
- Your application is Laravel but not Statamic — the value is the CP integration; without it you are paying for UI you cannot use.
- You need granular before/after diffs of content, legal hold, or per-tenant separation — scope these explicitly in a spike before promising them to a stakeholder.
De-risk before adoption: confirm Statamic version support, retention/purge behavior, PII handling in logged payloads (log scrubbing is often the compliance failure point), DB growth at your event volume, and whether CSV export respects access controls.
How to Pitch It (Stakeholders)
To executives: "We have a recurring need to prove who changed what in our CMS — it shows up in client security reviews and it slows down incident triage. There's a small MIT-licensed add-on that gives us the audit log, an admin UI, analytics, and CSV export for auditors, at roughly a day or two of integration instead of several weeks of engineering. It's low-cost and reversible; the main caveat is that it's a small open-source project, so we should treat it as an internal tool and keep the option to fork it if it becomes load-bearing."
To engineering: "Statamic add-on, DB-backed system + user audit logs, CP listing with filters, basic analytics, CSV export. MIT, one maintainer, nine stars, no dependents — so pin the version, review the migration and event-capture surface, and confirm it doesn't log sensitive fields. Treat it as a starting point we may need to own; don't let it become an unowned black box in the compliance path."
To compliance/security: "It provides activity evidence and exportable reports. It is not tamper-evident and not a substitute for centralized log retention — if the control requires immutability or off-system retention, we'll layer that on or build it, and we should say so up front rather than after the audit."