Statamic Logger Laravel Package

Product Decisions This Supports

• Build vs. buy for audit logging: This package is the "buy" option for a Statamic-native activity/audit trail. It answers the recurring roadmap question — do we build an in-house event logger (listeners + custom storage + a Control Panel viewer + retention policy) or adopt a maintained addon? — and lets you redirect engineering capacity toward product features instead of plumbing.
• Compliance and governance roadmap: Supports decisions on whether to ship SOC 2 / GDPR / internal-controls style requirements (who changed what, when, from where). A vetted, maintained logger is a prerequisite for committing to audit-trail language in enterprise sales conversations and security questionnaires.
• Editorial accountability feature: Enables user-facing "who edited/published/deleted this entry" history, revert-by-human investigation, and support triage — a commonly requested capability for multi-author, multi-site content teams.
• Incident response and support SLAs: Informs decisions about how fast the team can answer "what happened to this page?" without database spelunking. Logging immediacy is now a product-level question (see release note below), not just an infra detail.
• Observability vendor consolidation: A data point for the "do we need a full APM/SIEM vendor?" decision — lightweight, in-app logging covers the 80% case for content operations; it does not replace enterprise observability.
• Release 3.0.3 signal — synchronous logging by default: Removing ShouldQueue means log entries are written inline during the request rather than dispatched to a queue worker. Product implications: logs are immediate and no longer silently depend on a healthy queue worker (better for compliance guarantees and for teams without queue infrastructure), at the cost of a small per-request latency budget on high-traffic sites. If any roadmap item assumed "logging happens asynchronously / off the critical path," revisit that assumption, and confirm queue-monitoring alerts in your runbooks are no longer load-bearing for audit completeness.

When to Consider This Package

Adopt when:

• The application is Statamic 3/4/5 on Laravel and you want change/user activity visibility without building it.
• You need a configurable audit trail — select which events matter (content saved/published/deleted, user auth events, etc.), route them to a log channel, and control retention.
• Non-technical stakeholders need to read the logs; an in-CP viewer materially changes adoption versus raw log files.
• You have no dedicated observability stack, or you want content-ops auditing separated from application-error monitoring.
• Compliance, agency handover, or client-facing reporting requires a defensible record of editorial changes.

Look elsewhere when:

• You need tamper-evident, immutable, or externally-shipped audit logs (append-only storage, SIEM forwarding, WORM retention) — this is application-level logging, not a compliance-grade audit system.
• You already run Statamic's built-in action/audit logging and it satisfies the requirement — validate feature parity before adding a dependency.
• Volume is extreme (very high write throughput) and the now-synchronous write path becomes a measurable latency cost; budget for benchmarking and possibly a custom queued channel.
• You need cross-application or infrastructure telemetry (traces, metrics, error aggregation) — use a dedicated platform.
• The project is not Statamic — the value proposition collapses to a generic Laravel logger you can assemble in an afternoon.
• You require vendor-backed SLAs; this is a single-maintainer open-source addon — assess bus factor and pin versions accordingly.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost addon that gives us a defensible record of who changed what content and when. It directly supports the questions enterprise buyers and auditors ask, and it reduces the time support and editorial teams spend reconstructing "what happened" — a recurring cost we currently absorb manually. It is bought, not built: adopting it avoids weeks of engineering on plumbing we would otherwise have to maintain forever. The 3.0.3 update makes logging immediate and removes a hidden dependency on background queue workers, which improves the reliability of the audit record and simplifies operations. Risk is contained: it is an open-source addon with a single maintainer, so we pin the version and treat it as replaceable.

For engineering: Statamic-native addon that subscribes to Statamic/Laravel events, writes them through configurable log channels, and exposes them in the Control Panel. 3.0.3 removes ShouldQueue from the logging path — dispatch is now synchronous, so entries are written in-request: no worker required, no queue-lag gap in the audit trail, at the cost of inline write latency. Action items: benchmark the write path on our highest-traffic templates, confirm nothing in our config or docs still assumes queued dispatch or ordering, and verify log volume/retention settings so we don't grow storage unexpectedly. Pin the version and keep our event selection configuration in version control so we can swap implementations if maintenance stalls.