Security logs
How users see their own security-related events through GET /me/security/logs, backed by the internal logs Durable Object cache (not a separate DB table for this list).
Related: Logs architecture · Cache architecture · public Security overview.
Endpoint
| Method | Path | Behavior |
|---|---|---|
GET | /me/security/logs | List current user’s security/auth logs |
DELETE | /me/security/logs | Policy response — retention / who may delete is operator-defined |
DELETE | /me/security/logs/{id} | Same policy response |
Query: limit (default 100, max 500), optional cursor, level, category (auth | security).
Response: { data: InternalLogEntry[], pagination: { limit, nextCursor?, hasMore } }.
Code:
- Route:
apps/worker/src/routes/me/security.ts - Service:
apps/worker/src/lib/services/me/logs/(listUserLogs) - Zod:
SecurityLogsQuerySchemainlib/services/zod/me/security.ts - Types:
UserLogsListOptions/UserLogsListResultinsrc/types/me/logs.ts
What users see
Entries that include their userId, typically:
- Lockouts (
category: security,level: suspicious) - Login failures (invalid password, attempt counts)
- Login / register / logout success (
category: auth) - Other security events written with that
userId
System-wide health logs without userId stay out of this list.
How listing works
listUserLogscallsinternalLogger.getLogs({ userId, … })- Multi-shard reader prefers the per-user index (
internal:userindex:{userId}) whenuserIdis set - Cursor pagination (
timestamp:id) — no offset pages - Optional filters:
level,category
See logs.md for indexes, monthly shards, and the multi-shard reader.
Who should write with userId
| Area | Expectation |
|---|---|
| Auth login / register / logout | Always set userId (and ipAddress when known) |
| Profile / password / session revoke | Set userId on security-relevant events |
| 2FA / secure-action | Set userId so events appear in the user list |
| Maintenance | Use logger methods that accept userId when the action is user-attributable |
| Admin actions on a user | Log with the target user’s id when audit visibility is desired |
| System health | Omit userId (stays out of /me/security/logs) |
Facade: InternalLoggerService — logAuthEvent, logSecurityEvent, logUserEvent, logMaintenance, suspicious, etc.
Related
- Logs architecture
- Cache architecture
- Ownership — retention policy for the instance