Skip to main content
Status Sign in

Audit log

A multi-tenant platform without an audit log is one customer-trust incident away from a hard conversation. PowersportOS records every administrative mutation that affects tenant data, a tamper-evident timeline of who-did-what-when, available on the admin tenant detail page today and headed to the tenant portal when first multi-user customer asks.

What gets logged

The audit log captures admin actions that change tenant state. Reads aren't logged (performance + signal-to-noise tradeoff). Tenant-user mutations are visible to the tenant directly (My Catalog edits etc.) and aren't relayed to the admin audit log unless they cross into admin-managed territory.

Tenant lifecycle
Create, update, delete. Type changes (STANDARD → MANUFACTURER, etc.). Parent/child relationship changes.
Tenant user management
Create tenant user, password reset, delete tenant user. The temporary password is never logged, only the act of generating one.
API-key rotation
Old key invalidated, new key generated. Timestamp + actor recorded.
Brand subscriptions
Subscribe / unsubscribe. Auto-activation of parts from a brand subscription is itself captured.
Shopify install state
Generate install link, clear installation. The token is never logged, only the change in install state.
Catalog management from admin
Add part to tenant catalog, remove from tenant catalog, change activation state, edit per-tenant overrides.

What's captured per entry

  • Actor. Admin user ID, name, email. Pulled from the session, not a free-text input.
  • Action type. Enum value matching the operation performed.
  • Target. Tenant ID + tenant slug at time of action (so renames don't break historical references).
  • Diff / payload. Action-specific JSON capturing the meaningful before/after state. For sensitive fields (passwords, API keys), only the fact of change is stored, never the values.
  • Timestamp. UTC, microsecond precision.

Where it shows up

Today: a tab on each tenant detail page in the admin. Newest events first. Filter by action type, actor, or date range. Click a row to see the full diff payload.

Roadmap items not yet built:

  • Tenant-facing audit log. Show tenant users what their own users did inside the portal (catalog edits, dealer updates, stock pushes, etc.). Builds when first chain or distributor customer asks to see their own users' actions.
  • Admin auth events. Sign-in, sign-out, failed login attempts on admin accounts. Currently logged at the application layer but not surfaced in the audit-log UI. Easy add when needed.
  • Export to SIEM. Streaming the audit-log table to a customer's external SIEM or log-aggregation service. Customer-by-customer integration when the first enterprise customer asks.

Retention

All audit-log rows are retained for the life of the platform. Nightly database backups to Hetzner Storage Box include the audit-log table. No automatic pruning, no archival rotation. Storage cost is negligible (~1 KB per entry, low-thousands of entries per active customer per year).

Why this matters strategically

Audit logs are table-stakes for any enterprise sales conversation, especially with distributor-tier prospects who have their own compliance posture to defend. The log is also a useful operational tool: when a customer asks "did someone reset our API key yesterday?", the answer is one query, not an archaeology dig through application logs.