Auth and storage watchers
Adding watchers for authentication events and filesystem access — tracking logins, logouts, failures, and file reads/writes as first-class signals.
The next stretch of the sprint is a run of watchers and dashboard sections. First up: authentication and storage watchers.
Watching auth
Auth events are security gold: logins, logouts, failed attempts, password resets, new registrations. A burst of failures from one IP is a brute-force attempt. A login from an unusual place is worth a second look. So I added a MonitoringAuthEvent watcher and a Laravel AuthMonitoringInstrumentation that hooks Laravel's auth events and reports them — event type, guard, user label, IP, user agent.
Two deliberate choices:
- Opt-in. Auth data is sensitive, so the watcher is off by default (
LOOKOUT_AUTH_MONITORING_ENABLED). You turn it on knowingly. - Never transmit credentials. It records that a login failed, never the password tried. That's a line you do not cross in an observability tool.
Watching the filesystem
Storage is the other new watcher: file reads, writes, and deletes as trace spans (file.read / file.write / file.delete). The wrinkle is that Laravel's filesystem fires no native events — so the SDK decorates the default disk app-wide at boot to intercept operations. Because that's invasive, it's also opt-in.
The pattern underneath
Both of these slot into a watcher system I'd already shaped: a central registry maps each signal to its model, its enable flag, and its sampling rate. Adding a watcher is mostly declaring it. That's what let me ship two today and then immediately port them to other SDKs and drive them from remote config.
Next: making these watchers work in Rails and WordPress too.