Skip to content

Read the audit log

Audit → Read logs. A table of every audit entry, newest first, with rich filters along the top.

Each row shows:

  • Timestamp — when (relative + absolute on hover).
  • Type — the event type as a chip with colour by family (auth, user, admin, security).
  • Actor — who; click to jump to their record.
  • Target — what was acted on; click to jump.
  • Outcome — success / failure / denied / partial, with colour.

Click any row to expand. The expanded view shows:

  • The full data payload (the operation-specific fields).
  • The context (IP, user agent, fingerprint visitor id + confidence, geolocation if available).
  • The request id (for cross-referencing logs in your downstream systems).

Filter panel along the top:

  • Time range — last 15 min / hour / 24h / 7d / 30d / custom. Custom takes a start + end.
  • Type — multi-select from the closed taxonomy. The picker is grouped by family for easy scanning.
  • Outcome — success / failure / denied / partial.
  • Actor — search for the actor user / admin. Filter by id or email.
  • Target — search for the target. Filter by id.
  • Context.ip — exact IP or CIDR range.
  • Free text — substring search across all fields.

Filters AND together. Combine for precise queries.

A few patterns that come up often:

  • Time range: last hour.
  • Type: user.signed_in.failed.
  • Open a few entries. The data.error_code field tells you why.

If you see a spike of invalid_credentials, normal user error. If you see account_locked, brute-force defence kicked in — check the affected IPs.

  • Time range: yesterday.
  • Actor: search for anita@cymmetri.com.

Every action she took. Useful for offboarding reviews + occasional curiosity.

  • Time range: last week.
  • Type: admin.policy_updated.

Each entry shows the actor + the diff of what changed. Useful for "did someone slip a policy change in last sprint that nobody mentioned?"

  • Time range: incident window (e.g., 14:00 to 14:30 yesterday).
  • Type: any from the admin.* family.

The full set of changes operators made during the incident. Critical for post-incident review.

"Show me every admin operation by this specific support engineer"

Section titled “"Show me every admin operation by this specific support engineer"”
  • Actor: their email.
  • Type: admin family.

Useful for periodic review of support team's actions, or when a customer says "your support changed something on my account that I didn't authorise" and you need to investigate.

Default sort: newest first. You can change to oldest first (useful for "the first event of this kind") or by duration (for events that have a duration field, like flow runs).

Per-column sort isn't available — the audit log is fundamentally time-ordered.

After applying filters, click Save query. Name it. Saved queries appear in the left sidebar; one-click to rerun. Useful for queries you run regularly:

  • "Failed sign-ins in the last 24h"
  • "All admin policy changes this week"
  • "Brute-force detections, all time"

Saved queries are per-user. Sharing across the team means re-creating; we may add team-shared queries in a future release.

The table paginates 100 entries per page. Going past page 10 (1,000 entries) is fine but slow on very large tenants (~5 seconds for the next page). For longer-range investigations, prefer the export pattern + grep through the file locally — see Export.

From any event:

  • Click the actor → jumps to their user / admin record.
  • Click the target → jumps to that user / application / etc.
  • Click the request id → opens a filtered audit view showing every event with that request id (the platform threads request ids across events so you can reconstruct an end-to-end flow).

A toggle at the top right — Live. When on, the table auto-refreshes every 5 seconds, showing new events as they arrive. Useful during incident response or when you're verifying a config change is taking effect.

Live tail is bandwidth-cheap (small JSON payload per refresh). Leave it on for hours if useful.