How should a B2B SaaS product design its customer-facing audit log?

Illustrative situation: a prospect’s security team sends a review questionnaire. Two lines decide the deal: “Can our admins see who changed what, with time and IP address?” and “Can the logs go to our SIEM?” The product has an events table that engineers query. Its rows read “update_record” and “user 4417”. The scene is invented, but the pattern is common: the log exists for developers, and the customer-facing version is promised before anyone designs it.

Humbleteam, a digital product design agency, publishes this guide. It treats the audit log as a product with readers, a vocabulary and promises, and it includes a schema worksheet and an invented worked example. Vendor behavior below is described as of October 29, 2026 and can change.

Who reads an audit log, and what does each reader need?

Four people open it, with different questions:

• An admin asks “who changed this?” and needs one plain sentence.
• A security analyst looks for patterns, such as many exports in an hour, and needs filters, an API and a stream.
• An auditor needs a date range, a complete export and a statement of what the log leaves out.
• Your support team has to explain an event without asking engineering.

Access is usually narrow. Linear says only workspace owners can open its audit log, given the sensitive nature of the information. Notion offers it to organization owners, and Figma to organization admins only. Who may read the log is covered in our roles and permissions guide.

Which events belong in the log, and what does each one record?

Start from the reviewer’s questions, not your database. OWASP’s logging guidance says each record must show “when, where, who and what.” Slack’s Audit Logs API names the parts actor, action, entity and context, and adds optional details such as the previous value of a changed setting. GitHub’s enterprise audit log also records the affected user, the country, the actor’s single sign-on identity and, for actions outside the web interface, how the actor authenticated.

Our suggestion for categories: sign-ins and sessions, people and roles, sharing and export, security settings, API keys and integrations, billing, and support access. Notion’s audit log lists “Granted support access” among its account events.

Record the source as its own field. Notion records whether a user, an integration or an external AI tool acted, and shows actions taken with an admin token under an admin bot. Atlassian says the actor may be a user or the Atlassian system. OWASP notes that an event’s time can differ from the time it was logged, so store both.

How should events be named in plain words?

Okta’s System Log query guide pairs a machine name that filters use, such as user.session.access_admin_app, with a human message: “User accessing Okta Admin Console app.” Notion’s labels read as short past-tense phrases: “Page moved to trash,” “Password changed,” “Member added to teamspace.” Figma’s activity log uses “Trashed a file” and “Exported a file.”

Our suggestions:

• Name the thing and what happened: “Role changed,” not “Update.”
• Give each label one state. Figma lists some on-off pairs under one label, such as “AI features enabled/disabled.” In our reading, an analyst who filters for “disabled” needs two events instead.
• Group labels into categories, as Notion does.
• Treat the machine name as an API, because customers write SIEM rules against it.
• Plan for growth. Slack says its list of actions is incomplete. WorkOS, a vendor that sells audit logging, adds a new version for each change to an event definition, so old integrations keep working.

What should the list view and filters do?

Build the list as an ordinary table, using the rules in our data table and filters guide. Four log-specific choices remain.

First, offer filters for actor, target, event type and date. Notion filters by organization, date, person or agent, event and teamspace. Figma filters by member, date, event and team. Linear’s audit log filters by event type in the interface, but filtering by actor, email, IP or date range needs its API. A reviewer will find that gap.

Second, say what the list shows now. Atlassian’s audit log opens on the past 7 days, requires an exact search term, and warns that new events may take a few minutes. Google publishes lag times from a couple of minutes to a few hours, depending on the log. State the window and the delay.

Third, decide what happens to people who leave. Notion keeps removed users searchable under a “Removed” label. Figma says activity cannot be reviewed for members after they are removed. We suggest Notion’s approach, because a departure often matters most to an investigation.

Fourth, connect related events. Notion’s “Related” filter finds events from one underlying action, such as a page move that also changes permissions.

What should the event detail view show?

Atlassian’s detail panel lets an admin copy the event as JSON. Our suggested order: one sentence on top, such as “A. Rowan changed J. Alder’s role from Member to Admin”; the worksheet fields underneath, in the same order every time; a “Copy JSON” action for the analyst; a related-events link; and a link to the target, or the words “This member no longer exists.” Add a note on what the log never contains. Slack’s API does not monitor message content, and Notion’s stream carries no page content.

How should export and streaming work?

Exports behave differently. Atlassian emails a CSV of up to 10,000 activities from the past 180 days, with a link that expires after one day; a filtered search exports only the filtered rows. Notion’s CSV also follows the active filters. Figma’s CSV ignores other filters and covers the chosen date range. GitHub exports JSON or CSV. The export dialog should say whether filters apply, the row cap, the time zone and how the file arrives.

For an API, Slack’s is Enterprise-only and read-only, and Linear uses GraphQL. Figma’s Activity Logs API is for Enterprise organizations and mentions SIEM use. Microsoft’s Management Activity API lets organizations keep audit data past the default 180 days and import it into a SIEM.

Streaming is where products differ most, and each limit becomes a screen:

• GitHub’s stream supports Amazon S3, Azure Event Hubs, Datadog, Google Cloud Storage, Splunk and more. It runs a health check every 24 hours, emails owners about a bad setup, and delivers at least once, so events can repeat. A paused stream keeps a seven-day buffer.
• Okta’s log streaming goes to Amazon EventBridge or Splunk Cloud, with no filtering and no replay. It can deliver events out of order or twice, and it deactivates the stream if the target stops acknowledging.
• Atlassian’s webhooks allow three per organization, retry three times, and promise no order and no public service levels.
• Notion’s SIEM webhook allows one per workspace, retries up to seven times over about 24 hours, and leaves out organization events.
• Google’s export to Security Operations sends only events created after you connect.

Our suggestion is a Streams screen showing the destination, a status of active, paused or failing, the last successful delivery, the last error in plain words, the start time and what is excluded. Email admins when delivery fails, and give every event an ID for de-duplication.

What should the log say about retention?

There is no standard number. Okta and Linear keep 90 days. GitHub keeps 180 days, and Git events seven. Atlassian’s view page says 180 days, while its plan page says that from October 1, 2026 the Guard plan keeps 365. Google keeps most logs six months and says administrators cannot delete log data or change how long it is kept. Notion keeps 365 days. Microsoft keeps 180 days in Audit (Standard) and up to one year in Audit (Premium).

Pick a number you can defend, and print it on the screen. Our suggestion: a header line such as “Events are kept for 180 days. Oldest available: May 3,” a date picker that stops at that date, and Atlassian’s advice to export regularly, since older events cannot be recovered. If customers can change the period, log who changed it. The GDPR asks that personal data be kept identifiable no longer than necessary, and OWASP says logs should not be destroyed early or kept beyond the required period.

What do lower plans see?

Enterprise is the common gate. Slack’s Audit Logs API, Linear’s and Notion’s logs, and Figma’s API are Enterprise features, though Figma’s interface log also covers its Organization plan. Atlassian ties organization logs to a Guard or Enterprise subscription; without one, the log “will not store or display any events.” Microsoft goes the other way, enabling Audit (Standard) by default and selling longer retention.

The trap is the start date. Notion records events only from the time of upgrade. Figma says its log cannot be applied retroactively. Atlassian says an upgrade does not recover earlier events. A customer who upgrades after an incident opens an empty log.

Our suggestion for the lower-plan screen: name the plan, list what the log records, and say when recording starts. Consider recording from day one while gating access; none of the sources says a vendor does that, and it costs storage. Put the same facts on your pricing and security pages, because reviewers read them before purchase. Our billing and plan changes guide covers wording what a plan switches off.

What can you claim about tamper evidence?

Claim only what you built. The sources support three levels:

• Read-only for customers. Slack’s API has no write methods for audit events, and Google says administrators cannot delete log data.
• Detectable change. AWS CloudTrail’s log file validation hashes every file and signs hourly digests, so changes or deletions can be detected. Its mechanism is published.
• Protection and monitoring. OWASP asks for protection from tampering and deletion, and for detection when logging stops.

None of the other vendor pages read for this guide describes signed or write-once storage, and a page that does not mention them does not show they are missing. Write “customers cannot edit or delete events” if that is true. Write “tamper-proof” or “immutable” only if storage enforces it and you can show how. Record changes to log settings as events too.

What should the log leave out for privacy reasons?

OWASP lists what to keep out of logs or mask: passwords, access tokens, session IDs, payment data, encryption keys and sensitive personal data. Atlassian lets admins choose whether page titles and work item identifiers are stored in its log. GitHub shows actor IP addresses only after an enterprise enables it, and says the enterprise is responsible for the legal obligations that come with showing or storing them. GDPR Recital 30 names IP addresses as online identifiers, and Article 5 asks that personal data be limited to what is necessary.

That gives the design team three decisions: log IDs instead of content where you can, make IP display a documented choice, and decide whether a removed person’s history stays. Have counsel review the answers. This guide is not legal advice.

Illustrative worked example: a contract-review product meets a security review

Everything here is invented. Plinthwell is a fictional contract-review product. Glorbex Freight, a fictional customer on the Business plan, is reviewing Enterprise. Their security analyst asks four questions: who changed access, can it reach their SIEM, how long is it kept, and what happens to history if they leave the plan?

The team writes six launch events: sign-in, member invited, role changed, contract exported, API key created and single sign-on setting changed, each following the worksheet. The list opens on the last 7 days, under the line “Events can take a few minutes to appear. Kept for 365 days.” The analyst filters by “Contract exported” and sees 14 exports within an hour, all from one source: an API key labeled “Reporting script, ending 4f2a.” The detail panel names the key’s creator and links to the key’s creation.

The export dialog reads: “Export 1,230 events, Nov 1 to Nov 7. Filters apply. Times in UTC. We will email a link that works for 24 hours.” The Streams screen shows status “Failing since 09:02,” last delivery 08:57, and the reason “Your endpoint rejected our token.” Admins get an email at 09:30.

The team stores contract IDs, not titles, with a setting to show titles. On the Business plan, the page says the log is an Enterprise feature and lists what it records. The team decides to record from day one and unlock the earlier 30 days on upgrade. For tamper evidence it writes: “Customers can read and export this log. They cannot edit or delete events.” It does not write “immutable.”

Where do these defaults stop working?

The sources here are vendor documentation, OWASP guidance and the GDPR text. They show how products behave, not how your customers will use the log. No study of audit log screens in B2B products was found, and none is claimed. Atlassian’s own pages gave different retention figures on October 29, 2026, which shows how fast this detail drifts. This guide leaves out certification audits, legal hold, regional storage rules and the choice to buy a logging service instead of building one.

What can you produce now?

Five things, before anyone draws a screen:

1. An event catalog with a plain label, category and machine name for each event.
2. The schema worksheet, filled in for your six most requested events.
3. A written statement of retention, plan access, and what is and is not logged.
4. A spec for export and streaming: formats, caps, failure states and who is told.
5. A test list: removed actor, deleted target, failed stream, lag, duplicate event, downgrade and upgrade.

With those you can decide the open questions: who reads the log, how long it is kept, and what you will promise about tampering. If you plan to bring in outside designers, ask each team to fill in the worksheet for two events and explain the Streams screen. Our comparison of UX/UI agencies that design complex B2B SaaS platforms shows which studios publish work on screens like these.