Statamic Logger Laravel Package

Technical Evaluation

Package: mitydigital/statamic-logger — a Statamic addon that records control-panel and content lifecycle events (entry saves, publishes, deletions, user/auth activity) into Laravel's logging/audit surface.

Release under review: 3.0.3 — "Remove ShouldQueue" (PR #23). This is a small diff with a disproportionately large behavioural footprint: whatever class previously implemented ShouldQueue (most likely the event listener/subscriber or the audit-write job) now executes synchronously inside the originating request. This is the single most important fact in the assessment and it needs to be treated as a behavioural change, not a patch-level cosmetic.

Architecture fit. The package sits cleanly in the Laravel/Statamic idiom: service provider registration, event subscriber on Statamic's event surface, config-driven channel/target selection. It does not introduce a parallel persistence model or its own migration-heavy schema, which keeps it low-coupling and easy to remove. The synchronous model is actually a better architectural fit for an audit trail — audit records that can silently fail in a queue are weak evidence. Synchronous writes give you "if the entry saved, the audit row exists" atomicity-adjacent semantics, which is what compliance and incident review actually want.

Integration feasibility. High. Standard composer install plus provider registration in a Statamic addon context; no infrastructure prerequisites beyond what a Statamic site already has. The removal of ShouldQueue reduces integration prerequisites (no queue worker, no failed_jobs monitoring, no supervisor config) — this notably makes the package viable on single-container or serverless-style deployments where a persistent worker was previously a blocker.

Technical risk. Concentrated in three areas:

1. Request-path latency. Every logged event now pays the write cost inline. For CP edits this is negligible; for programmatic bulk operations (imports, migrations, seeders, API-driven content sync) it is linear and compounding.
2. Failure propagation. A queued job that throws is retried and parked in failed_jobs. A synchronous listener that throws can surface as a 500 on the user's save action depending on how Statamic's event dispatcher and the package's own exception handling are wired. This is the highest-severity unknown.
3. Silent behavioural drift for existing installs. Teams on 3.0.2 may have tuned queue connection, retries, and worker concurrency for this package specifically. Upgrading changes the execution model without changing any config key — nothing in the app will visibly break, but throughput and failure characteristics shift. That is the classic "works in staging, degrades in prod bulk-import" trap.

Key questions.

• Which class lost ShouldQueue, and is the removal a deliberate design decision (audit durability) or a bug fix for queued-context breakage (e.g. serialisation failures, missing tenant context after deserialisation)? The answer determines whether to expect this to be re-added behind a config flag.
• Is the synchronous write wrapped in try/catch, or can it fail the parent request? Is there a report() path that preserves the original user action?
• Does the package still expose a config toggle for queueing, or is synchronous now the only mode? Was this documented as breaking?
• What's the measured cost per logged event (one insert? one channel write? multiple events per save)?
• Does 3.0.3 change the public API (interfaces, config keys, published assets) or only internal behaviour? Semver says patch, but ShouldQueue removal is arguably minor-or-major in effect.
• Is there a retention/pruning story now that writes are guaranteed rather than best-effort? Guaranteed writes plus no pruning equals unbounded table growth.

Integration Approach

Stack fit. Native. Laravel 10/11 + Statamic 4/5, no exotic dependencies, no Node/build step, no external service. It slots in alongside existing logging (Monolog channels, Telescope, Sentry) rather than competing with them — this is domain-event auditing, not application logging, and the distinction should be made explicit to the team so nobody duplicates effort.

Migration path. Low effort, non-trivial verification.

• Greenfield: install 3.0.3 directly. Nothing to migrate; synchronous is the default and only behaviour. No worker required — a genuine simplification of the deployment topology.
• From 3.0.2: treat as a behaviour change requiring a release note in your own changelog, not a silent composer update. Before merging: confirm the config surface is unchanged, grep your codebase for any assumption that logging is deferred (e.g. tests that assert on log rows immediately after a queued action, dashboards that read the audit table, alerting that keys off failed_jobs entries from this package).
• If you were relying on the queue for backpressure during large content operations, that safety valve is gone. Plan to disable the logger (or use the package's channel config to route to a null/stack handler) during one-off bulk operations, or accept the inline cost.

Compatibility. PHP version floor and Statamic major version pins are the things to verify — a patch bump that removes an interface implementation occasionally rides along with a dependency constraint change. Check composer.json diff between 3.0.2 and 3.0.3 before approving. Multi-tenant and multi-site Statamic installs should be explicitly tested, since synchronous execution means the audit write inherits the current request's site/tenant context rather than the serialised job payload's — this is usually desirable (correct attribution) but is a behavioural difference worth a test case.

Sequencing.

1. Read the PR diff and the class that lost ShouldQueue; determine failure semantics.
2. Upgrade in a lower environment; run the CP edit / publish / delete happy paths and confirm audit rows appear with correct actor and site context.
3. Deliberately trigger a write failure (revoke DB permission, point the channel at a bad path) and observe whether the parent save succeeds or 500s. This is the go/no-go test.
4. Benchmark a bulk operation (e.g. 500-entry import) with the logger on vs. off to quantify inline cost.
5. Roll to production during a quiet window, with the ability to disable the package via config rather than a redeploy.
6. Update internal runbooks: queue worker no longer relevant for this package; audit-table growth monitoring now relevant.

Operational Impact

Maintenance. Slight net reduction. One fewer moving part to keep healthy (no worker, no queue backlog, no failed_jobs triage for this package), and a smaller surface for "why didn't the log appear" investigations — it either wrote or the request failed. Counterweight: you now own data volume. Synchronous writes are reliable, so the table (or log channel) grows predictably with content activity, including bulk operations that previously might have partially dropped. Budget for a pruning/retention job if the package doesn't ship one.

Support. The failure mode shifts from "silent gap, discovered during an audit months later" to "visible error at the moment of action." That's better for integrity and worse for user experience if unhandled. Support scripts should include: check application error logs for audit-write exceptions correlated with CP save failures; check whether the package was disabled during a bulk import (explaining an expected gap). Expect at least one incident where a support engineer sees "audit logging broke content editing" — have the config-level kill switch documented before, not after.

Scaling. The key change. Horizontal request scaling now carries the logging cost; previously that cost was absorbed by worker capacity, which you could scale independently. For typical Statamic CP traffic (tens of edits/minute) this is immaterial. For high-volume programmatic content pipelines, API-driven ingestion, or sync-from-PIM/CRM jobs, the cost is now on the critical path and cannot be amortised by adding workers. If such a pipeline exists, this is the deciding factor: either route those operations through a logging-disabled context, or accept the added latency per write. Also note writes now serialise against the request's DB connection/pool — high-concurrency imports can contend on the audit table.

Failure modes.

• Write failure fails the user action (worst case, unknown): a DB blip becomes a content-editing outage. Mitigation: verify catch-and-report semantics; if absent, raise upstream or wrap.
• Write failure silently swallowed (best case): audit gap with no signal. Mitigation: metric/alert on expected-vs-actual audit volume.
• Latency creep under bulk load: no alert fires, jobs just take longer, timeouts appear downstream. Mitigation: benchmark and set a per-operation budget.
• Unbounded growth: disk or table bloat months out. Mitigation: retention policy from day one.
• Upgrade surprise: someone runs composer update and changes execution semantics without a review gate. Mitigation: pin, and treat 3.0.3 as a reviewable change in your dependency policy.

Ramp-up. Effectively zero for a developer adding a channel or reading the config — it's a config-first package with Statamic-idiomatic registration. The ramp-up cost is entirely on the operations side and is conceptual rather than syntactic: the team must internalise that this logger is now on the synchronous request path and therefore part of the availability and latency budget, not a background concern. That reframing is the one piece of education this release demands, and it's worth a short written note in the platform runbook rather than a meeting.

Verdict. Adopt 3.0.3 for new integrations — synchronous audit writes are the correct default for integrity-sensitive logging and the deployment simplification is real. For existing 3.0.2 installs, upgrade deliberately after confirming failure semantics and quantifying bulk-operation cost; the version number understates the change.