Skip to content
Knowledge sections

Audit events and notifications

Persisted governance records and user-facing messages for workspace activity.

auditnotificationsgovernance
On this page

Audit Events and Notifications are two distinct concepts the starter does not conflate.

Audit Events

An Audit Event is a persisted, queryable record of a governance-sensitive action. Each row in the audit_events D1 table captures actorUserId, targetType, targetId, an eventType string, and a metadata JSON blob. AuditEventLog.list (requires WorkspaceContext from the route layer) exposes pages of 100 events ordered most-recent-first with optional server-side filters (actorUserId, eventType, since/until) and keyset pagination via an opaque cursor; raw metadata is deliberately off the wire. AuditEventLog.listGlobal remains an unfiltered top-100 for /admin.

Today the starter writes Audit Events via AuditEventLog.record for: API token lifecycle (api_token.created, api_token.revoked: there is deliberately no per-request api_token.used event; lastUsedAt is the activity signal), webhook endpoint mutations (webhook_endpoint.created / .disabled / .secret_rotated), terminal webhook delivery outcomes (webhook.delivery_failed, webhook.delivery_dead_lettered), membership changes (workspace_member.added / .removed / .role_changed), invitation lifecycle (workspace_invitation.sent / .canceled / .accepted), workspace lifecycle (workspace.created, workspace.renamed, and workspace.deleted: the delete is a system event with no workspace attribution, so it survives the cascade that removes the workspace it describes), and the account lifecycle on the auth catchall: credential sign-in (auth.sign_in, auth.sign_in_failed), sign-up (auth.sign_up, auth.sign_up_failed), password reset requests (auth.password_reset_requested: one unattributed event per request, matching the endpoint's non-disclosing constant response), the reset itself (auth.password_reset, auth.password_reset_failed), and email verification (auth.email_verified, auth.email_verification_failed). The workspace export lifecycle is audited by WorkspaceExports (workspace.export_requested by the owner; workspace.export_completed and workspace.export_downloaded as system events written by the background and API workers). Billing mutations are audited by the Billing capability (billing.checkout_started when a member opens checkout, billing.plan_changed as a system event written atomically with the provider-driven workspaces.planId update).

Notifications

A Notification is a user-facing message about workspace, billing, integration, or API token activity. The NotificationFeed capability exposes one write, notify, for background jobs: the workspace export consumer uses it to tell the requester their archive is ready. No write path derives Notifications from Audit Events automatically.

Why they're separate

Audit Events are inspectable evidence; Notifications are attention-routing. Conflating them either makes the audit trail noisy with non-governance content, or makes notifications a partial governance log that lies by omission. Wide-event logs already carry a traceId for request correlation; the audit_events row does not yet store one, so add it to the metadata JSON when instrumenting writes if you need to join them.