Filament User Activity Laravel Package

Product Decisions This Supports

• Build vs. buy for presence/activity features. "Currently active users" and per-user activity trails are recurring requests in admin/back-office products. This package lets you satisfy them with a Filament plugin instead of owning middleware, event listeners, and a widget from scratch — a clear buy decision for a non-differentiating feature.
• Roadmap sequencing for internal tooling. If your roadmap includes admin observability (who's online, who last touched a record, support staff availability), this is a low-cost way to ship a v1 and learn whether users actually use presence data before investing in a real-time or audit-grade solution.
• Feature scoping: internal vs. customer-facing. Presence is table-stakes in an internal Filament panel but rarely a selling point. This supports the decision to keep it out of the customer-facing surface and treat it as an ops convenience.
• Support and operations use cases. "Who is currently active" shortens incident triage ("is the user actually in the app right now?"), helps support reps time outreach, and gives admins a lightweight sense of adoption and seat utilization without a separate analytics tool.
• De-risking an audit/compliance conversation. Activity tracking here is operational, not evidentiary. Using it clarifies the gap between "we can see recent activity" and "we have a tamper-evident audit log," which is itself a useful input to whether to invest in a compliance-grade trail.

When to Consider This Package

Adopt when: you are already running Filament and want a working "active users" widget in days, not sprints; the audience is internal admins/ops, not end customers; you can tolerate a small, single-maintainer, MIT-licensed community package (22 stars, 0 dependents); and you are comfortable pinning a version and reading the source before shipping.

Look elsewhere when: you need compliance-grade or immutable audit logging (evaluate spatie/laravel-activitylog or Laravel Auditing instead); you need true real-time presence at scale across multiple apps (WebSockets/Redis + Laravel Echo/Pusher is the right architecture); you need a maintenance SLA or vendor support; you need presence outside the Filament UI (API, mobile, customer-facing); or you have a policy against low-adoption dependencies in production. Mitigations if you proceed anyway: vendor or fork the package, wrap it behind your own interface, and add integration tests so an upstream stall or breaking change is a swap, not a rewrite.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) add-on that gives our admin team visibility into who is using the platform right now — useful for support responsiveness and seat-utilization insight — without a build cycle or a new vendor contract. It is an internal productivity feature, not a customer-facing differentiator, so we should treat it as a low-cost experiment with an easy exit.

To engineering: A Filament plugin that records user activity and renders an active-users view. Integration is configuration-level, no schema redesign, no new infrastructure. Caveats to accept explicitly: low adoption (22 stars, 0 dependents), single maintainer, recent releases — so we pin the version, keep it behind our own abstraction, and do not let it become our audit log. If presence ever needs to be real-time or customer-facing, we graduate to a WebSocket/Redis approach and this package becomes the throwaway prototype.