Audit → Read logs. A table of every audit entry, newest first, with rich filters along the top.
The table
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
datapayload (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).
Filters
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.
Common queries
A few patterns that come up often:
"Why did sign-ins fail in the last hour?"
Time range: last hour.
Type:
user.signed_in.failed.Open a few entries. The
data.error_codefield 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.
"What did Anita do yesterday?"
Time range: yesterday.
Actor: search for
anita@cymmetri.com.
Every action she took. Useful for offboarding reviews + occasional curiosity.
"Who changed the authentication policy last week?"
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?"
"What admin actions happened during the incident window?"
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"
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.
Sort
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.
Save a query
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.
Pagination + perf
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.
Drill-down
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).
Live tail
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.