UX Patterns Guide
UI + UX Data Display And Exploration established

Activity log

Provide an activity log with structured event records, actor/action/object anatomy, powerful filtering and search, visible scope and retention limits, event details, redaction and delay states, export behavior, and clear distinctions from summaries, notifications, and user-controlled history.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Users need to inspect recorded user, admin, system, security, or integration events.
  • Events must support troubleshooting, compliance, incident response, permission review, or operational proof.
  • Actor, action, object, timestamp, source, result, and technical context matter.
  • The product can expose scope, retention, permissions, details, filtering, and export behavior honestly.

Avoid when

  • The goal is only to show a readable milestone history for one case or process.
  • The surface is a personal notification inbox or collaboration stream.
  • The activity is user-managed search history with deletion and pause controls.
  • The backend cannot provide reliable event records, scope, retention, or timestamps.
  • Users need editable spreadsheet-like event analysis beyond what the log UI can support.

Problem it prevents

Organizations and power users need to understand who did what, to which object, from where, and when, but ordinary timelines, feeds, notifications, and history pages often omit the evidence, scope, retention, and export behavior required for investigation.

Pattern anatomy

What a strong implementation has to make clear

User need

Events may come from users, admins, service accounts, automation, integrations, or system processes.

Pattern promise

Provide an activity log with structured event records, actor/action/object anatomy, powerful filtering and search, visible scope and retention limits, event details, redaction and delay states, export behavior, and clear distinctions from summaries, notifications, and user-controlled history.

Required state

Default log state with event records, result count, visible timezone, retention window, and permission scope.

Recovery path

A log record lacks actor, action, object, timestamp, or event ID and cannot support investigation.

Access contract

Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields.
  • A filtered security log displays 'admin role changes, last 7 days, UTC, 42 records, 3 redacted by scope' with Export CSV and Save query controls.
  • An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive.
  • A support lead opens a user-access event and sees actor, object, changed role, IP address, source app, timestamp in UTC, and redacted fields caused by permission scope.
Weak implementation

Vague, hidden, hard to recover from

  • A page titled Activity shows vague entries such as Changed settings with no actor, target, timestamp, or source.
  • An export button downloads a different date range and timezone than the on-screen filtered log.
  • A user marks a notification read and the corresponding activity evidence disappears from the only log.
  • A security analyst searches for a deleted repository event but the UI hides that Git events have shorter retention.
UI guidance
  • Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available.
  • Expose filters, query syntax, retention window, permission scope, redaction, export, and timezone state directly beside the results so users know what the visible log does and does not prove.
UX guidance
  • Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries.
  • Protect trust by showing provenance and limitations: delayed ingestion, redacted fields, duplicated streamed events, retention cutoffs, scoped access, export range, and whether records are immutable or corrected.
Implementation contract

What the implementation must handle

States

  • Default log state with event records, result count, visible timezone, retention window, and permission scope.
  • Filtered and searched states by actor, action, object, app, date range, result, IP, location, or event ID.
  • Expanded event detail state with changed fields, source, event ID, request context, and related object route.
  • Export queued, export ready, export failed, and export range mismatch states.

Interaction

  • Each log row identifies one recorded event and keeps actor, action, object, timestamp, and event ID stable across filtering, sorting, expansion, export, and refresh.
  • Filters narrow visible records without deleting or mutating log evidence.
  • Search and date range controls state the timezone and included endpoints used by the query.
  • Opening details reveals additional evidence for the same event and does not summarize multiple events as one record.

Accessibility

  • Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together.
  • Give expansion, copy event ID, export, and related-object actions accessible names that include the event or row identity.
  • Expose active filters, result count, timezone, retention, redaction, loading, export, and failed-search status as text.
  • Do not rely on color alone for failed, redacted, warning, system, duplicate, or permission-limited events.

Review

  • What question does this log answer: who, what, when, where, before and after, or whether the record exists at all?
  • Which event fields are required for investigation, and which are unavailable, redacted, delayed, or out of retention?
  • Can users tell the active query, date range, timezone, result count, permission scope, and retention window?
  • Does export exactly match the on-screen query and field set, and does the UI say when it does not?
Interactive lab

Inspect the states before you copy the pattern

Investigate recorded system activity

Filter by event type, expand a record, copy the event ID, export the current query, switch timezone, reveal retention limits, and compare vague-events, hidden-scope, export-mismatch, read-clears, local-time-drift, and duplicate-stream failures.

Activity log
Loading interactive demo...

State To Inspect

Default log state with event records, result count, visible timezone, retention window, and permission scope.

Keyboard / Access

Tab reaches filter controls, search, date range, export, table rows, row expansion, copy event ID, and detail actions in predictable order.

Avoid Generating

Calling a social feed or notification drawer an activity log without event evidence.
Evidence trail

Source-backed claims behind this guidance

Full agent/debug reference

Problem Context

  • Events may come from users, admins, service accounts, automation, integrations, or system processes.
  • Users inspect the log for troubleshooting, security review, compliance, incident response, permission review, billing disputes, change review, or operational proof.
  • Records may have retention windows, role-gated access, redacted fields, delayed ingestion, duplicate delivery, timezone normalization, or export constraints.
  • The surface often spans multiple apps, workspaces, objects, groups, locations, devices, and event types.

Selection Rules

  • Choose activity log when the task is evidence review, investigation, compliance, security monitoring, or operational troubleshooting.
  • Use timeline when users only need a readable summary of important events for one object or process.
  • Use feed when users consume a live or personalized stream and reading position matters more than evidence completeness.
  • Use notification center when users need personal triage, unread state, badge behavior, and notification preferences.
  • Use search history when users manage their own stored query activity and deletion or pause controls are the primary need.
  • Use table or data grid when event records need dense column comparison, sortable fields, column selection, or export-ready row structure.
  • Include actor, action, object, timestamp, source, result, and event ID before adding visual summaries.
  • Show active filters, query, timezone, retention window, permission scope, and result count near the log.
  • Provide detail expansion for changed fields, request metadata, IP/location, source app, raw payload, or related records where appropriate.
  • Label redacted, delayed, duplicate, corrected, archived, failed-ingestion, unavailable, and out-of-retention states.
  • Do not promise deletion, completeness, or legal proof unless the retention and backend record model support that claim.
  • Design export and API access as first-class behavior when the log supports investigation beyond the UI.

Required States

  • Default log state with event records, result count, visible timezone, retention window, and permission scope.
  • Filtered and searched states by actor, action, object, app, date range, result, IP, location, or event ID.
  • Expanded event detail state with changed fields, source, event ID, request context, and related object route.
  • Export queued, export ready, export failed, and export range mismatch states.
  • No results, empty log, loading, delayed ingestion, offline, failed-load, and retry states.
  • Redacted, permission-limited, out-of-retention, archived, corrected, duplicate, and deleted-object states.
  • Saved query or copied query state when investigation workflows support reuse.
  • Responsive state where event identity and critical metadata remain readable without hiding scope.

Interaction Contract

  • Each log row identifies one recorded event and keeps actor, action, object, timestamp, and event ID stable across filtering, sorting, expansion, export, and refresh.
  • Filters narrow visible records without deleting or mutating log evidence.
  • Search and date range controls state the timezone and included endpoints used by the query.
  • Opening details reveals additional evidence for the same event and does not summarize multiple events as one record.
  • Export uses the same query, range, timezone, fields, and permission scope shown on screen or explains the difference before export.
  • Redacted or unavailable fields explain whether data is hidden by permissions, policy, retention, ingestion delay, or source-system loss.
  • Records are not removed by notification read state, user-facing dismissal, or personal history deletion unless the backend policy explicitly allows it.
  • After refresh, export, expansion, or filter changes, focus remains near the triggering control or updated result summary.

Implementation Checklist

  • Define event schema: event ID, timestamp, timezone, actor, actor type, action, object, object type, source app, result, IP, location, request ID, before and after fields, retention class, and export eligibility.
  • Separate activity-log records from feeds, notification records, search history, analytics events, and timeline summaries in the data model.
  • Build filters for actor, action, object, app, result, event type, date range, IP/location, and event ID according to real investigative tasks.
  • Display active query, scope, result count, timezone, retention window, ingestion freshness, and permission limitations near the log.
  • Implement details, copy event ID, copy query, saved query, export, retry, and archive routes with explicit status feedback.
  • Model redaction, retention cutoff, duplicates, corrected timestamps, delayed ingestion, failed export, deleted objects, and scoped administrator access.
  • Test long actor names, service accounts, missing IPs, redacted fields, partial exports, timezone changes, virtualized rows, keyboard expansion, screen-reader row identity, and mobile metadata wrapping.
  • Audit telemetry so sensitive log contents are not leaked into unrelated analytics while still recording use of log controls.

Common Generated-UI Mistakes

  • Calling a social feed or notification drawer an activity log without event evidence.
  • Using vague activity labels that omit actor, action, object, timestamp, or result.
  • Hiding retention limits, permission scope, or redaction until after users fail to find records.
  • Letting mark-read, dismiss, archive, or personal-history deletion remove administrative evidence.
  • Showing local browser time in the UI while export uses UTC without disclosure.
  • Exporting a different field set, date range, or filter query than the visible results.
  • Treating streamed duplicate events as separate confirmed actions without duplicate indicators.
  • Using activity log as a timeline summary when users need searchable, exportable records.

Critique Questions

  • What question does this log answer: who, what, when, where, before and after, or whether the record exists at all?
  • Which event fields are required for investigation, and which are unavailable, redacted, delayed, or out of retention?
  • Can users tell the active query, date range, timezone, result count, permission scope, and retention window?
  • Does export exactly match the on-screen query and field set, and does the UI say when it does not?
  • What happens to log records when notifications are read, objects are deleted, users leave, or personal history is cleared?
  • Would timeline, feed, notification center, search history, table, or data grid better fit this surface?
Accessibility
  • Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together.
  • Give expansion, copy event ID, export, and related-object actions accessible names that include the event or row identity.
  • Expose active filters, result count, timezone, retention, redaction, loading, export, and failed-search status as text.
  • Do not rely on color alone for failed, redacted, warning, system, duplicate, or permission-limited events.
  • Keep detail drawers or expanded rows keyboard reachable and return focus to the invoking row control when closed.
  • For virtualized logs, preserve row identity, focus, and loaded range announcements when rows mount or unmount.
Keyboard Behavior
  • Tab reaches filter controls, search, date range, export, table rows, row expansion, copy event ID, and detail actions in predictable order.
  • Enter or Space activates row expansion, filter apply, copy, export, retry, and saved-query actions according to native control behavior.
  • Escape closes row details, filter popovers, or export dialogs and returns focus to the invoking control.
  • After applying filters, focus remains on the filter control or moves to a result summary rather than the page top.
  • After expanding a row, focus stays on the row control unless the product deliberately moves it to the detail heading.
  • After export starts or fails, focus remains near the export status and the status is announced.
Variants
  • Organization audit log
  • Security activity log
  • Admin activity log
  • User activity log
  • Object change log
  • Access log
  • Compliance log
  • Integration event log
  • Exportable audit log
  • Scoped activity log
  • Activity log with saved query
  • Activity log with event details

Verification

Last verified: