For Admins

Audit logs

What gets logged, how to filter and search the audit trail, retention, and exporting for compliance.

Who can use this: Org admins only.

The audit log is the immutable record of who did what in your Performance Blocks organization. It's the safety net under every other surface — when something looks wrong, the audit log tells you what happened. When compliance asks, the audit log is the answer.

This article covers what gets logged, how to read and filter the log, retention, and exporting.

Audit logs are immutable. Entries cannot be edited or deleted by anyone, including org admins, including Performance Blocks staff. This is the central design property — an audit log you can edit isn't an audit log.

What gets logged

Performance Blocks logs every consequential action. The categories:

Authentication and sessions

  • Successful sign-in, with IP and user agent.
  • Failed sign-in attempts (rate-limited; we don't log every brute-force attempt).
  • Sign-out.
  • Session expiry.
  • SSO sign-ins (with the IdP that issued the assertion).
  • Magic link clicks (during invitation flow).

User and role changes

  • Employee creation (manual, CSV import, HRIS sync, SCIM).
  • Role assignment and revocation.
  • Reporting line changes.
  • Department and custom field changes.
  • Lifecycle transitions (deactivate, reactivate, archive).
  • Email changes (including verification).

Performance content

  • Observation create, edit, delete.
  • Conversation create, message added.
  • Summary create, status change (draft → pending → approved → archived).
  • Objective create, edit, delete, status change.
  • 360 cycle launch, response submission, finalization.
  • Attribute rating create, edit.

Settings changes

  • Any change in Settings → Organization, Branding, Features, Departments, Attributes, Custom Fields, Review Cycles, Review Flags.
  • Each entry captures the before and after value (sensitive fields like API keys are masked).

Moderation

  • Flag fired (which rule, which artifact).
  • Flag resolved (approve, return, reject, escalate).
  • Notes attached to flag decisions.

Integrations

  • Integration connected/disconnected (Slack, Teams, Chrome, HRIS).
  • API key created, used, rotated, revoked.
  • Webhook deliveries (success/failure).
  • HRIS sync runs (duration, records added/updated/removed).

Billing

  • Plan changes (upgrade, downgrade).
  • Payment method updates.
  • Invoice events (issued, paid, failed).
  • Seat count changes.

Henry agent (Agentic plan)

  • Henry conversations initiated.
  • Henry actions taken (create observation via Henry, etc.).
  • Knowledge base document upload, delete.

Admin impersonation

If a Performance Blocks support engineer impersonates a user in your org for support purposes (always with explicit consent), every action under impersonation is logged with the engineer's identity, the impersonated user, and the start/end of the impersonation session.

What is not logged

The audit log is not a debug log. We don't capture:

  • Page views (unless they trigger an action).
  • Search queries.
  • Filter changes.
  • Read-only API calls (these are rate-logged but not audit-logged).

If you need to know "did Alice read Bob's summary," the answer is: if Bob's summary is shared with Alice, she can read it; we don't log each read. For most compliance scenarios this is fine; for stricter scenarios, contact support to discuss.

Reading the log

Open Admin → Audit Log to see entries.

Each row shows:

  • Timestamp in your org timezone (with tooltip showing UTC).
  • Actor — who did the thing (user, system, integration).
  • Action — a structured verb like observation.create or settings.features.update.
  • Target — what the action was on (employee, observation, summary).
  • Source — web, Slack, Teams, Chrome, API, integration, system.
  • IP and user agent — for human actors only.

Click a row to expand and see:

  • The full detail of the change (before/after values for updates).
  • Any associated notes.
  • Related entries (e.g., a summary status.change shows the previous status and the next).

Filters

The log supports filters for the most common queries:

  • Date range — start and end. Default last 30 days.
  • Actor — pick a user, system, or integration.
  • Action type — pick from a structured list (with grouping by category).
  • Target type — employee, observation, summary, conversation, etc.
  • Target ID — for "everything that happened to this specific employee/summary."
  • Source — web, Slack, etc.
  • IP — useful for "who signed in from this IP."

You can combine filters. The most common queries:

  • "What changed for employee X in the last 60 days" — filter by target ID.
  • "Who modified settings last week" — filter by action type starting with settings. and date range.
  • "What did admin Y do" — filter by actor.

A free-text search box matches against actor name, target name, and the body of the change. Useful when you don't know the exact filter combination.

Retention

Audit logs are retained according to your plan and your Settings → Audit Log Settings retention configuration.

Plan Default retention Maximum retention
Team 12 months 24 months
Agentic 24 months 7 years

Within the maximum, you can configure your retention in Settings → Audit Log Settings:

  1. Open Admin → Settings → Audit Log Settings.
  2. Set Retention period to the value you want.
  3. Save.

Entries older than the retention period are deleted automatically each month. You cannot recover deleted entries; export first if you need long-term records.

If your industry has specific retention requirements (SOX, HIPAA, etc.), set retention to match. For most organizations, 24 months is the right balance between completeness and storage.

Exporting

To export the audit log:

  1. Open Admin → Audit Log.
  2. Apply any filters you want.
  3. Click Export.
  4. Choose CSV (for spreadsheet analysis) or JSON (for programmatic processing).
  5. The export is generated and emailed to you when ready (large exports can take a few minutes).

Exports include all visible columns plus the full change detail. Sensitive values (API keys, password hashes) are masked in exports the same way they're masked in the UI.

For periodic compliance exports, you can also schedule monthly exports — see Settings → Audit Log Settings → Scheduled exports. Scheduled exports email a CSV to a configured address on the first of each month.

Programmatic access

On the Agentic plan, the audit log is also accessible via the API:

  • GET /api/audit-log — paginated list with filter support.
  • GET /api/audit-log/{id} — fetch a specific entry.

The API uses the same filters as the UI. See API reference for endpoint details and rate limits.

Common compliance use cases

Patterns that come up repeatedly:

"We need to prove Alice didn't see her review before our approval"

Filter the audit log by:

  • Target ID = Alice's summary
  • Date range = creation to approval

You'll see every action on the summary including the status.change entries. Until status is approved, the employee cannot see the content.

"Did anyone change feature flags last month"

Filter by:

  • Action type = settings.features.update
  • Date range = last month

Every change is listed with actor, before, and after values.

"Did admin Bob impersonate anyone last quarter"

Filter by:

  • Actor = Bob
  • Action type = impersonation.start or impersonation.end

You'll see every impersonation session.

"Why was this employee deactivated"

Filter by:

  • Target ID = employee
  • Action type = employee.deactivate

The entry shows who deactivated, when, and any note attached.

Performance and limits

For orgs with significant volume, the audit log can be large. Practical notes:

  • Filter before paginating — unfiltered queries on large logs are slow.
  • Use date ranges aggressively — the default is 30 days for a reason.
  • For analysis on millions of entries, export and use a real analytics tool. The UI is for spot-checking and incident response, not OLAP.

Tampering and integrity

Audit log entries are append-only. The implementation enforces this at the database level (RESTRICT foreign keys, no UPDATE/DELETE permissions on the table). If an admin tries to delete an entry via any UI or API path, the request is rejected.

For organizations with strict integrity requirements, we offer (on request) hash-chained audit log export — each entry includes a hash of the previous entry's hash, allowing you to verify that no entries were deleted from a sequence. Contact support to enable.

Frequently asked

Can I edit a log entry to add context? No — entries are immutable. You can attach notes to specific entries (these are tracked separately, not edits to the original entry).

Can I delete entries about a specific employee under GDPR right-to-erasure? Yes — for genuine right-to-erasure requests, contact support. We will redact (not delete) personal identifiers in entries about that employee. The redaction itself is logged.

Why don't I see my own actions immediately? Audit log writes are async with a few-second delay to avoid blocking user actions. Refresh after 5–10 seconds.

Are audit logs encrypted at rest? Yes — all data including audit logs is encrypted at rest. See Security overview for full crypto details.

Can other admins see my actions? Yes — admins can see all admin actions. There is no admin-of-admins restriction.

Next steps

© 2026 Performance Blocks. All rights reserved.