Review your site's audit log
How to read the Activity Log of admin events on a site, filter by what matters, search across the history, export a slice, and shape retention.
The Activity Log is the running record of what happened in the SGEN admin.
Every meaningful action by a signed-in user — content published, settings changed, user created, backup run, restore performed — becomes one entry in the log.
The log is how you reconstruct the timeline of a change, confirm who did what, and produce a record for a compliance reviewer or an internal post-mortem.
This page is the operator-side walk-through of the log.
The first half is reading: what gets recorded, where to find it, how to filter and search.
The second half is producing: how to export a slice for handoff and how retention shapes what stays in the log over time.
What is this for?
Use the log when you need to answer one of three questions.
What changed? when a setting is in an unexpected state and you want to see when and by whom.
Who did this? when an action surprised the team and you need attribution.
What did we do? when a reviewer or auditor asks for evidence that the team is operating with discipline.
The log is the customer-facing surface for this.
It does not replace platform-level operational telemetry, which the platform team owns and is not exposed to operators.
A fourth read mode is increasingly useful — what is normal?
Reviewing the log over a quiet week builds a sense of what a healthy week looks like on the site.
That baseline makes the unusual entries jump off the page on the next review.
Good use cases
- A setting reverted and the team needs to find when, and who triggered the change.
- A new user appeared on the site and you want to confirm who provisioned the account.
- A compliance reviewer asks for a record of admin sign-ins for the last quarter.
- A backup ran at an unexpected time and you want to confirm whether it was manual or scheduled.
- An automation fired and you want to confirm the trigger event that originated the chain.
- A page content change does not match the editor's last save; the log shows whether a second edit ran in parallel.
- The team needs a quarterly summary of admin activity for an internal report and wants to lift the numbers from a single source.
- An incident reviewer asks for the timeline of the last hour before the incident; the log carries the answer.
What NOT to use this for
- Per-page version diff.
- Public visitor analytics.
- Server-side error chase.
- Real-time alerting.
How this connects to other features
- Security — the log is one pillar of the wider site-security posture; sign-in events feed straight into it.
- Two-Factor and SSO — every 2FA challenge and SSO sign-in is recorded as a log entry.
- Back up and Restore — every backup, restore, and retention change appears in the log with the operator's note.
- SG-Admin Users — user-creation and role-change events flow from this surface to the log.
- Webhooks — webhook configuration changes and delivery summaries appear in the log.
- Manage Multiple Sites — the portfolio-level Activity view aggregates entries from every site in the org account.
Before you start
- You are signed in as a user with audit-read permission on the site.
- You know the rough time window of the event you are looking for.
- For an export, you know who is going to read it and what they expect — the export shape can be tuned for that.
- For an incident review, you know what entry types you expect to find before opening the log; that way you can spot the gap if the expected entry is missing.
- For a compliance handoff, you know the retention window the reviewer expects and have already confirmed the live log covers that window.
Where to find it
The Activity Log lives at the admin → Activity Log.
The page opens to the most recent entries, newest first.
Use the keyboard shortcut / to jump straight to the search box from anywhere on the page.
The search box is the right starting point when the question is "what touched the homepage in the last week."
A portfolio-level view sits at SG-Dashboard → Activity for users with access to multiple sites.
It aggregates the log across every site, with a site-pick filter to scope to one.
The portfolio view is the right entry point for any question that spans more than one site — a cross-site compliance review, an agency-wide weekly read, a question about whether a particular team member's actions ranged across the portfolio.
For per-site detail, click any row to land back in the per-site view with context preserved.
Steps
The workflow has four parts — understand what gets logged, filter and search, read an entry in detail, and export a slice. Retention review sits as a sub-step at the end.
1. Understand what gets logged
The log records admin actions grouped into five families.
- Identity — sign-in, sign-out, password change, 2FA enabled or disabled, SSO sign-in, recovery code used.
- Content — page published, page updated, page deleted, post published, post updated, post deleted, template changed.
- Settings — site settings change (any field; the entry names the field and the old and new values), permission change on a user, role change on a user.
- Backups and restore — backup taken, backup completed, backup failed, restore started, restore completed, retention rule changed, snapshot pinned or unpinned.
- Integrations and automations — webhook created or edited, webhook delivery summary, automation run, integration connected or disconnected.
System-triggered events that did not originate with an operator (a scheduled backup, an automated retention sweep) carry an actor of System and the trigger detail in the note.
A small number of events span more than one family — for example, a webhook delivery summary that fired because of a content publish.
The log records the primary family on the row and surfaces the cross-family relationship through the linked-entries view on the expanded detail panel.
Treat the expanded view as the right read for any cross-family question.
2. Filter and search
The filter row at the top of the log carries five filters.
Date range sets the window.
Default is the last 7 days.
The picker accepts presets — Today, Last 24 hours, Last 7 days, Last 30 days — and a custom range for arbitrary windows.
Event family narrows to one of the five families.
Tick more than one to combine.
Actor filters to events by one signed-in user.
The picker is type-ahead against the active user list for the site.
Event type narrows further, to a specific event such as page.published or user.role_changed.
This filter is dependent on the family filter — pick the family first.
Search is a substring match against the target and the note text.
Useful for finding "all events that touched the homepage" or "everything that mentions a specific user by name."
Filters combine with AND.
The result count appears above the table; the table updates live as filters change.
For complex searches that the filter row does not cover, click Advanced above the filter row.
The advanced panel exposes target-type and note-pattern filters for more specific queries.
Save a filter combination as a Saved view for habitual reads.
A typical agency saves "last 7 days, identity family, all sign-in events" as a daily-review view and "last 90 days, settings family" as a quarterly-review view.
Saved views appear in a dropdown above the filter row and stay scoped to the site.
3. Read an entry in detail
Click any row to expand the entry.
The detail panel opens to the right.
The panel shows the same fields as the row plus the full context.
Source — what surface the action came from (admin UI, integration, automation).
Session ID — the sign-in session that produced the event, useful for grouping a related sequence.
Before/After — for settings changes and role changes, the field-level diff of what changed.
For a backup, restore, or automation entry, the panel also shows the Linked entries list — related events that share the same correlation ID.
A restore entry, for example, links to the backup it pulled from; a backup entry links forward to any restore that used it.
For an identity entry, the panel shows the Source IP of the sign-in (where the platform's privacy posture allows it) and the User agent of the browser.
These help confirm whether a sign-in was the operator at their desk or something unexpected.
Click Copy Entry ID in the top right of the panel to capture a stable reference to the entry.
The ID is the right thing to paste into a ticket, a handoff note, or a follow-up message; clicking the ID later jumps straight to the entry.
For an entry that is part of a longer chain, use the Open chain action.
The view switches to a chain-mode display that shows every related entry in order, with the correlation ID at the top and arrows linking each step.
This view is the fastest path through a multi-step incident reconstruction.
4. Export a slice of the log
Once the filters scope to the events you want to hand off, click Export in the top right of the page.
The export panel opens with three choices.
Format picks the file format — spreadsheet for review, structured data for downstream processing, or a printable summary for a one-page report.
Fields ticks the columns to include.
Default is timestamp, actor, event family, event type, target, note.
Extend with source, session ID, before-and-after, or correlation ID when the receiver needs more context.
Filename sets the output filename.
Default is audit-log-.
Useful filenames carry the site, the window, and the purpose.
Click Generate Export.
The export runs as a background job; the page shows a progress indicator.
Small exports finish within a few seconds; large windows take longer.
The finished file appears in the Exports tab on the same page, available for download for seven days.
The Exports tab also records who triggered each export.
The export action itself appears in the log — exports are a recordable event.
5. Review retention
Open Retention at the bottom of the Activity Log page.
The current rule shows the active retention window — typically the last 12 months for most plans, with shorter or longer windows depending on the plan tier.
Events older than the retention window are removed from the index by the daily retention sweep.
Exported files generated before the sweep are unaffected — the export captures a moment and is not pruned with the live log.
The retention rule itself is configurable within the plan ceiling.
Adjust the slider, then click Save Retention.
The change applies on the next sweep.
For teams that need a defense-in-depth posture, combine a long live-log retention with an external archive of monthly exports.
The live log answers fast questions inside the active window; the archive answers the deeper-history question without depending on the live retention setting.
The two layers together produce a clean evidence story for any reviewer who asks "how do you keep this history."
What success looks like
A successful review session ends with the team holding a specific answer to the original question.
Either the answer is "here is the entry, here is the actor, here is the time" — pinned to a stable Entry ID anyone can revisit — or the review concludes the event did not happen within the retention window and the next step is escalation.
A successful export ends with a file that the downstream reader can act on — the file opens cleanly, the columns match what the reader expected, and the events are in the right window.
A healthy weekly review ends with no surprises and a short note in the team channel confirming the review ran.
A healthy quarterly compliance handoff ends with the reviewer signing off without a follow-up question because the export carried the right fields and the right window.
What to do if it does not work
- Entry I expected is not in the log.
- Actor field shows System for a change a person made.
- Filter result is empty for a known event.
- Export hangs at Generating.
- Linked entries panel is empty for a backup row.
- Source IP field shows blank on an identity entry.
- Advanced filter returns far more rows than expected.
- An export I started yesterday is not in the Exports tab.
Examples
Example A — finding who reverted a setting.
A team member notices the contact email on the site changed.
They open Activity Log, filter event family to Settings, set the date range to the last 7 days, and search for the field name.
One row appears — the setting was edited yesterday afternoon by a named user.
The expanded panel shows the before-and-after values.
The team confirms with the user that the change was intentional and updates the relevant documentation; the entry ID is pinned in the team's notes.
Example B — quarterly compliance export.
Compliance reviewer asks for all admin sign-in events for Q1.
Operator opens Activity Log, filters event family to Identity and event type to user.sign_in, sets the date range to January 1 to March 31, and clicks Export.
Format spreadsheet, fields include source IP and session ID.
Generated file lands in the Exports tab in under a minute.
Operator downloads, shares with the reviewer, and the export action itself appears in the log as audit evidence that the export was produced.
Example C — tracing an unexpected backup.
A backup ran overnight outside the scheduled cadence.
Operator opens Activity Log, filters event family to Backups and restore, sets the date range to the last 24 hours.
The row shows actor System with a note that names the trigger — a recently created automation that runs a backup when site settings change.
Operator opens the linked entries to see the settings change that triggered the cascade, confirms it was a routine update, and either disables the automation or accepts the new behavior.
Example D — confirming who deactivated a team member.
A team member realizes their colleague's account is no longer active.
The team lead opens Activity Log, filters event family to Identity, filters event type to user.deactivated, sets the date range to the last 30 days.
Two deactivation rows appear, with the colleague's email on one.
The expanded entry shows the actor — the org admin — and a brief note explaining the offboarding.
The lead pins the entry ID in the team's offboarding record, closing the loop on the question without any guesswork.
Example E — internal post-mortem after an editorial mistake.
A blog post went out with the wrong headline and the team wants to reconstruct the timeline.
The editor opens Activity Log, filters event family to Content, sorts by the post slug in the search box.
The log shows the draft creation, three saves with the wrong headline, the publish event, and an unpublish event four minutes later.
Each row links to the editor account and the source surface.
The team holds a short post-mortem the next day with the timeline on a single page, identifies the missed review step, and updates the editorial checklist.
Plan for compliance-grade and large-portfolio audit scenarios
The Activity Log is a customer-facing operational record. For a team operating under a compliance regime or running many sites, the log becomes a deliverable.
Long-horizon retention beyond the live window
The live log carries the platform-baseline retention window — typically the last 12 months for most plans.
For evidence that must survive longer, schedule monthly exports.
Open Activity Log, set the date range to the previous calendar month, export with the full field set, save the export to the team's own evidence archive.
A monthly export cycle produces a clean handoff to a quarterly reviewer.
The reviewer asks "show me admin activity for Q1"; the team hands over three monthly exports that cover the window with no gaps.
The exports themselves carry an Entry ID for the export action, so the chain of custody runs from the live log into the archive without breaks.
For multi-year retention, the team's archive — not the live log — is the source.
Plan the archive's storage and access patterns up front; the cost of the storage is small, and the cost of a missing month at audit time is large.
Cross-site compliance review
For an org account running many sites, the portfolio-level Activity surface in SG-Dashboard is the right entry point.
Filter to the relevant event family, scope to the period, and sweep across every site in one view.
For a compliance reviewer who needs evidence per site, export per-site slices and bundle them by site name.
Document the team's compliance-export cadence in the operating runbook.
A cadence that names the surface, the filter, the export shape, and the destination archive is a cadence that survives team turnover.
Each new owner reads the runbook, runs the cadence, and the evidence chain continues without interpretation.
Building team review habits
A log that nobody reads is a log that produces surprises.
Set a weekly habit — fifteen minutes on Monday morning, two people open the log together, filter to the last week, scan for anything unexpected.
Most weeks produce nothing; the weeks that produce something catch the issue early, before it compounds.
Pair the weekly habit with a quarterly drill.
Pick one entry at random, expand it, write a paragraph explaining what the entry shows and why it matters.
The drill keeps the team's reading skills fresh and produces a small library of worked examples that new team members read during onboarding.
Reference — populated log entry shape
A populated entry from an SGEN site, in the shape the Activity Log displays. The row carries the headline fields; the expanded detail panel carries the rest.
| Field | Example value |
|---|---|
| Timestamp (UTC) | 2026-05-22 14:03:18 |
| Actor | ada@yourteam.com |
| Event family | Content |
| Event type | post.published |
| Target | Post #4421 — Spring 2026 brewing guide |
| Source | Admin UI |
| Session ID | sess_2026_05_22_ada_3f01 |
| Note | (none) |
| Linked entries | 2 — webhook delivery summaries (slack-#editorial, search-index-invalidation) |
| Entry ID | evt_2026_05_22_a4b1c9d2 |
| Field | Example value |
|---|---|
| Timestamp (UTC) | 2026-05-22 13:51:04 |
| Actor | grace@yourteam.com |
| Event family | Settings |
| Event type | site.settings_changed |
| Target | contact_email |
| Before | hello@yourteam.com |
| After | support@yourteam.com |
| Note | "Routing inbound contact mail to support inbox." |
| Entry ID | evt_2026_05_22_d92c4a18 |
Reference — saved-view configurations for habitual reads
A team that reads the log on a cadence saves the right filter as a named view. The reference below shows five saved views that survive across most operating teams.
| Saved view name | Family filter | Event filter | Date range | Used for |
|---|---|---|---|---|
| Daily — identity health | Identity | All | Last 24 hours | Catch unexpected sign-ins early |
| Weekly — content cadence | Content | All | Last 7 days | Spot publishing surprises |
| Quarterly — compliance sign-ins | Identity | user.sign_in | Last 90 days | Reviewer-ready export |
| Incident lookback | All | All | Custom (last 4 hours) | Reconstruct an incident timeline |
| Backup activity | Backups and restore | All | Last 30 days | Confirm scheduled cadence is healthy |
Reference — export field set for common handoffs
The Export panel exposes a field-set picker. The right field set varies by who reads the export. The matrix below carries three common shapes.
| Receiver | Format | Fields ticked | Filename pattern |
|---|---|---|---|
| Internal compliance reviewer | Spreadsheet | Timestamp, Actor, Event family, Event type, Target, Note, Source IP, Session ID | audit-log-sgen-Q1-2026-compliance.xlsx |
| Incident post-mortem reader | Spreadsheet | Timestamp, Actor, Event type, Target, Note, Linked entries | audit-log-sgen-incident-INC-1184-timeline.xlsx |
| Quarterly internal report | Printable summary | Timestamp, Actor, Event family, Event type, Target | audit-log-sgen-Q1-2026-summary.pdf |
Reference — sign-in event detail populated example
The expanded panel for a sign-in entry carries the network signal as well as the identity signal. A populated example from an SGEN site.
Entry ID: evt_2026_05_22_e44d11b9Timestamp: 2026-05-22 14:08:42 UTCActor: grace@yourteam.comEvent family: IdentityEvent type: user.sign_in (SSO)Source: Identity provider — provider_okta_sgenSession ID: sess_2026_05_22_grace_8b21Source IP: 203.0.113.42User agent: Mozilla/5.0... Chrome/126.0Result: SuccessLinked entries: user.first_sign_in (same session), role.assigned (first_sign_in default)The expanded panel renders these fields in a clean table; the example above is the same information in a copyable text form for an incident handoff note.
Reference — log-entry-family signal strength for incident review
A small matrix that orients an incident reviewer to which family carries the right answer for a given question.
| Question | Best-fitting family | Best-fitting event type |
|---|---|---|
| Who signed in at 14:03? | Identity | user.sign_in |
| Which setting changed and to what value? | Settings | site.settings_changed |
| When was this post published? | Content | post.published |
| Did the scheduled backup run last night? | Backups and restore | backup.completed |
| Did the webhook deliver successfully? | Integrations and automations | webhook.delivered |
| Who deactivated this team member? | Identity | user.deactivated |
| Why did the search index update? | Content | page.updated / page.published |
| Was this restore manual or automated? | Backups and restore | restore.completed (actor field) |
Common questions about the audit log
How long does an entry stay in the log?
The retention window is the platform baseline for the active plan, tunable within the plan's ceiling.
Most plans run a 12-month window.
Plan tiers may extend the ceiling.
Check the Retention panel on the Activity Log page for the active window on the current site.
Is the log tamper-proof?
Entries are append-only from the customer side.
No customer-facing surface lets an operator edit or delete a log entry.
The platform team manages the log infrastructure separately and outside the customer admin surface.
For evidence-grade requirements, the recommended pattern is regular exports to the team's own archive, which adds an independent chain of custody.
Can I see what changed in a settings entry?
Yes — for settings-type entries the expanded detail panel shows the before-and-after values for each field that changed.
The same applies to role-change entries; the panel shows the old role and the new role for the target user.
Does the log capture page-body edits?
The log captures the publish event for a page or post, with the actor and the timestamp.
The body diff itself lives in the per-page revision history inside the admin Pages.
The two surfaces complement each other — the log answers "when and who"; the revision history answers "what changed in the body."
What about events from automations and scheduled jobs?
System-triggered events appear with the actor System and a note that names the underlying trigger.
The expanded detail panel surfaces the correlation chain — clicking through the linked entries traces back to the originating operator action that set the automation in motion.
Can I subscribe to log events in real time?
The log itself is a review surface, not an alerting surface.
For real-time signal, wire the matching event through Webhooks to a notification destination.
The Webhooks surface and the log work together — webhook delivery summaries also appear in the log, so the team has both the live signal and the retrospective record.