Skip to content
UX Atlas
Plate PAT·019 · PatternGrid F1 · Rev. 2026-09-14

Activity Timelines

A chronological record of what happened, which needs grouping and filtering to stay readable.

PatternCraft conventionIntermediate

Definition

A timeline presents events in chronological order, usually newest first. It answers what changed, when, and by whom, and it becomes unusable at volume without aggregation.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2Making a timeline usable
  3. 3Timelines that stay readable at volume
  4. 4Activity feed or audit log
  5. 5What each entry has to record
  6. 6Grouping is most of the design
  7. 7In practice
  8. 8Commonly confused with
  9. 9Local chart
  10. 10Continue from here

Reach for this when

  • Users need to understand what changed and who changed it.
  • Building audit and compliance surfaces.
  • Readers need to answer what changed, when, and by whom.

Common mistakes

  • One entry per atomic event.
  • Ambiguous or unlocalised timestamps.
  • No filtering at volume.

Making a timeline usable

  • Group related events: 'Sam edited 12 fields' rather than twelve entries.
  • Use relative time for recent events and absolute time for older ones, with the exact timestamp available on hover or focus.
  • State the actor, the action and the object in a single readable sentence.
  • Filter by actor, type and date range once volume passes a few dozen entries.
  • Show what changed, not only that something changed, wherever the diff is small enough to display.
  • Separate system events from human events visually, since they answer different questions.

Timelines that stay readable at volume

Do

  • Group related events, so twelve field edits read as one change.
  • Show relative time with the absolute timestamp available on hover or focus.
  • Filter by actor, type and date, since volume is the usual problem.
  • Say which timezone is being displayed.

Do not

  • Render every system event alongside human ones with equal weight.
  • Use relative time alone for anything auditable.
  • Load the entire history on open.
  • Let automated entries drown the two entries a person cared about.

Activity feed or audit log

They look alike and answer different questions. Building one and labelling it the other is the usual mistake.

QuestionActivity feedAudit log
Who is it forAnyone working on the objectAdministrators, security, compliance.
What is includedMeaningful, grouped eventsEverything, ungrouped, including failed attempts.
Can entries be hiddenYes, filtered or collapsedNo. Completeness is the point.
RetentionAs long as it stays usefulFixed by policy or regulation, and stated.
Time displayRelative, with absolute on demandAbsolute, with the timezone named, always.
ExportRarely neededRequired, in a machine-readable format.

What each entry has to record

  • The actor, distinguishing a person from an integration, an automation or the system itself.
  • The action, as a verb the reader would use, not the internal event name.
  • The object, linked, and still identifiable after it has been renamed or deleted.
  • The timestamp, with the timezone, and a format that cannot be misread across locales.
  • What changed, with before and after where the values are short enough to show.
  • The source, for anything auditable: which client, which session, which API key.

Grouping is most of the design

Ungroupedeight lines, one changeGroupedSam edited 12 fields09:14, with a link to the changesPriya commentedStatus changed to Shippedthe two entries a person cared about, still visible
The same events either bury the two entries a person cared about, or surface them. Nothing else about the component matters as much.

In practice

  1. i.

    Grouped edit events

    Collaboration tools

    Collapsing a burst of edits by one person within a short window into a single entry keeps the timeline about meaningful change rather than about keystrokes.

  2. ii.

    Four hundred entries, one that mattered

    Aggregation

    An audit trail logging every field change individually buried the status change somebody was looking for. Grouping by actor and time window made the same data readable without discarding any of it.

Commonly confused with

Close neighbours that get substituted for each other. The difference is stated first, then the condition that picks one over the other.

vs.

Notifications

Pattern

Messages delivered to a person because an event concerns them now.

Key difference

A timeline is a record of what happened to a thing, read on purpose. Notifications are pushed at a person because something needs their attention. The same event can appear in both, and only one of them should interrupt.

Use Activity Timelines when

  • The question is what changed, when, and by whom.
  • The events belong to an object rather than to a person.
  • Completeness matters more than urgency.

Use Notifications when

  • Someone needs to know without going to look.
  • The event is addressed to a person, not filed against a record.
  • You are deciding how loudly to interrupt.

Learn about Notifications

Local chart

PAT·019 · Region III · Grid F1

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

ForgivenessPRIN·006 · PRINCIPLES BEHIND THISContinuityFND·008 · PRINCIPLES BEHIND THISAvatarCMP·024 · OFTEN USED WITHData TableCMP·025 · OFTEN USED WITHCollaborationPAT·026 · OFTEN USED WITHFilteringPAT·004 · OFTEN USED WITHNotificationsPAT·015 · COMMONLY CONFUSED WITHInternationalizationWRT·006 · RELATED CONCEPT

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applies when you are designing

A DashboardAn Enterprise Workflow

Principles behind this

The reasoning this solution is an application of.

Often used with

These usually appear in the same screen or the same decision.

Related concept

Connected closely enough to change how you apply this.