Filament Activitylog Laravel Package

Product Decisions This Supports

• Audit trail and activity logging features: The package now automatically stamps every log entry with properties.ip, properties.via, and properties.agent, making it viable for user-facing audit histories, security forensics, and compliance evidence without bespoke plumbing in every controller, job, or listener.
• Build vs. buy for observability plumbing: Teams can stop building and maintaining request-context middleware, log processors, and CLI/web branching logic. This release directly replaces a common piece of custom Laravel infrastructure with a configuration flag (logging.stamp_request).
• Roadmap prioritization: Product and engineering can spend roadmap capacity on customer-facing capabilities rather than on making logs consistently attributable. This is especially relevant for products with multi-tenant, multi-channel, or agent-driven activity where "who did what, from where, and through which client" is a recurring requirement.
• Incident response and support workflows: Because entries now self-describe the request context, support and on-call engineers can trace an issue to a client address, route/channel (via), and user agent without correlating multiple systems or asking customers for reproduction details.
• Consistency across entry points: The feature applies "whoever wrote it," which supports decisions about standardizing logging across web requests, queued jobs, and CLI-invoked workflows. The deliberate choice to key off client address rather than runningInConsole() means test suites and production behave consistently, reducing "works in staging, fails in prod" logging gaps.

When to Consider This Package

Consider adoption when:

• You are building or operating a Laravel application that needs structured, attributable audit logs — user activity, admin actions, security-relevant events, or customer-facing activity feeds.
• Your current logging requires manual stamping of request metadata in every place you log, or you have inconsistent context because some entry points forget to set it.
• You need logging behavior that is consistent between CLI/test environments and live web traffic, and you have been bitten by SAPI-based branching (runningInConsole()).
• You want a low-ceremony, framework-native approach rather than standing up a full APM or external observability platform for basic request context.
• You value backward-compatible feature releases — this release adds automatic stamping while leaving caller-set keys untouched, which lowers upgrade risk.

Look elsewhere when:

• You are not on Laravel/PHP, or your logging stack is already standardized on an external platform (e.g., OpenTelemetry, Datadog) where request context is injected by the runtime.
• You need full distributed tracing, metrics, or APM — this package addresses structured context on log entries, not end-to-end observability.
• You have extremely high log volume and require sampling, buffering, or transport-level controls beyond what the package provides.
• You need strict schema governance or PII redaction guarantees that are not documented; evaluate whether ip and agent collection meets your privacy and data-retention policies before adopting.

How to Pitch It (Stakeholders)

To executives: This release removes a recurring engineering tax — every team that logs an event currently has to manually attach request context, and inevitably some paths miss it. With logging.stamp_request, every entry is automatically attributable to a client address, channel, and user agent. That means faster incident resolution, stronger audit evidence for compliance and security reviews, and less custom code to maintain. It is a configuration-level change with no breaking changes, so the cost and risk of adoption are low.

To engineering: The package now fills the context rail itself instead of relying on every call site to stamp properties.ip, properties.via, and properties.agent. Caller-set values are preserved, so existing custom enrichment still works. The implementation deliberately checks the client address rather than runningInConsole(), which means behavior under test matches behavior in production — a meaningful correctness improvement over the common SAPI-based shortcut. Adopt it by enabling logging.stamp_request; no changes to existing log calls are required.