Audit History Guide

What the audit log captures

Every configuration write, flag evaluation change, and permission modification in Zenmanage is recorded in the audit log. The record is immutable — it cannot be altered or deleted retroactively. Each entry contains:

• Actor identity: the team member who made the change, identified by name and email address
• Timestamp: the exact time the change was applied, with millisecond precision
• Environment: which environment the change occurred in — production, staging, development, or any custom environment you have configured
• Action type: what was done — flag enabled, rollout percentage changed, targeting rule updated, environment variable written, permission modified
• Full diff: the before and after state of the changed configuration, so you can see exactly what value changed and what it changed from

The log is queryable by environment, actor, action type, and time window. You do not need to export or parse raw logs — investigation starts inside the Zenmanage interface.

Accessing the audit log

The audit log is accessible from two places, depending on the scope of your investigation.

1. Project-level log: Open a project, then go to Settings → Audit Log. This shows all changes within that project across all environments. Use this for incident investigations scoped to a single product area.
2. Account-level log: Go to Account Settings → Audit Log. This shows all changes across all projects and environments, including permission changes. Use this for org-wide compliance reviews or when the incident spans multiple projects.

Read-only access to the audit log can be granted to compliance reviewers and operations leads without giving them write access to any environment. See the Scoped Permissions Setup Guide for how to configure audit-only roles.

Querying the audit log

Use the filter controls at the top of the audit log to narrow your investigation. Filters can be combined.

Incident investigation workflow

When an incident occurs in production and you suspect a configuration change is involved, use the following workflow to reconstruct the timeline.

1. 1. Establish the incident window. Identify the approximate start time of the incident from your observability stack — the first error spike, alert trigger, or user report. Note the timestamp. This becomes your upper bound for the audit search.
2. 2. Open the project-level audit log and filter to production. Set the time window to 30–60 minutes before the incident start time through to the current moment. This captures any changes that could have caused or contributed to the incident.
3. 3. Scan for flag enables, disables, and rollout changes. These are the most common sources of production behavior changes. Look for entries with action types flag enabled, flag disabled, rollout started, rollout percentage changed, or targeting rule updated.
4. 4. Expand the diff for any suspicious entry. The diff shows the before and after state. If a flag was enabled that triggers new code behavior, or a rollout was increased that expanded exposure to a regression, the diff will confirm it.
5. 5. Correlate with your observability timeline. Cross-reference the audit log timestamp with your error rate graphs and latency charts. A change at 14:22:08 that correlates with a spike at 14:22:15 is strong evidence of cause.
6. 6. Confirm the actor. Every entry includes the team member who made the change. This is not for blame — it is for contact. If the change was intentional, the actor is the right person to involve in the remediation decision.
7. 7. Take action. If the audit log confirms a change caused the incident, use the appropriate mitigation: disable the flag, pause the rollout, or revert the targeting rule. All of these changes will themselves be logged in the audit trail.

Release timeline reconstruction

The audit log provides a complete, chronological record of every configuration change. This makes it well-suited for reconstructing release timelines — useful both during post-incident reviews and as an input to change management processes.

To reconstruct the timeline of a specific release:

1. 1. Filter by flag key. This shows every change to that flag: when it was created, when it was published to staging, when it was enabled in production, any mid-rollout changes, and when it was completed or removed.
2. 2. Add the environment filter for production. Narrow to production-only changes to get a clean view of the release progression.
3. 3. Export the filtered log. The audit log can be exported as CSV or JSON for inclusion in post-mortems, incident reports, or compliance documentation.

Compliance review workflow

The immutable audit log supports compliance review processes without requiring bespoke tooling or manual log reconstruction. Use the following workflow when preparing for a compliance review or audit.

1. 1. Scope the review period. Set a time window that covers the review period — typically a calendar quarter, a release cycle, or the period since your last audit.
2. 2. Review production flag changes. Filter to production, action type: all flag changes. This gives a record of every flag enable, disable, and configuration change that affected live users.
3. 3. Review permission changes. Use the account-level audit log and filter for action type: permission changes. This shows every role assignment, revocation, and access change across all projects and environments during the review period.
4. 4. Verify actor attribution. For each significant change, confirm that the actor is a known, authorized team member. The audit log links each entry to an identity that cannot be altered retroactively.
5. 5. Export the filtered log. Export as CSV or JSON for your compliance documentation. The export includes all visible fields — actor, timestamp, environment, action, diff.