# Activity and audit history

Review who changed organisation and project resources without exposing runtime data.

Organisation Activity is the durable customer-facing record of control-plane changes. Project
Activity shows the project-relevant subset.

Use activity to answer who changed a resource, what changed, when it changed, and which project or
environment was affected. Use Insights for aggregate runtime traffic instead.

## Open and filter activity

Open **Activity** from the organisation navigation for the complete organisation feed. Open a project's
Activity tab when the investigation is limited to that project.

Search and filters narrow the feed by humanized event category and resource. Begin with the incident
time window, then filter by flag, key, project, environment, or membership action.

Activity is not a raw database change stream. Events are designed for customer investigation and
retain stable actor and resource context without exposing secrets.

## Recorded changes

Activity can include:

- Flag creation, identity, lifecycle, and archive changes.
- Environment fallbacks, targeting, and change notes.
- Kill-switch trigger and restoration.
- Environment create, archive, restore, and delete actions.
- Runtime and client key creation or revocation.
- Project rename, archive, transfer, restore, and delete actions.
- Member invitations, roles, removal, leave, and ownership transfer.
- Organisation identity, defaults, billing, and lifecycle changes.

Availability depends on the shipped action. Absence of an event is not proof that a local application
branch did not run; local evaluation is outside the activity model.

## Actors and credentials

Human changes identify the signed-in actor. Automation changes identify the management credential or
safe key metadata available to the event.

Key events can display name, type, scope, environment, and prefix. Raw one-time secrets are never
recoverable from activity.

When a project transfers, historical attribution stays in the source organisation. Transfer events
are written for source and destination so current ownership can be reconstructed without rewriting history.

## Write useful change notes

A production note should include:

- Why the change is needed.
- The expected observation window.
- The owner of the decision.
- The rollback condition.
- A privacy-safe incident or work reference when appropriate.

Do not paste emails, keys, tokens, cookies, authorization headers, raw context, targeting values,
request bodies, user agents, IP addresses, or resolved values.

## Audit versus analytics

Activity records management actions. Project Insights summarizes hosted requests, errors, rate limits,
environment volume, and direct per-flag totals.

Neither surface records every local SDK evaluation. Neither should be presented as user exposure or
conversion analytics.

## Investigate a configuration incident

1. Establish the application incident time.
2. Filter project activity to the affected flag or environment.
3. Review fallback, targeting, key, and kill-switch events.
4. Identify the actor and change note.
5. Compare hosted errors and rate limits in Insights.
6. Correlate with application deployments and telemetry.
7. Record the repair without adding sensitive payloads.

## Retention and export expectations

Use FeatureGate activity as the platform record, not as the only copy of an organisation's compliance
process. Export or retain required records according to organisational policy and plan capabilities.

The public Management API exposes a narrow project audit subset only. It is not a replacement for the
complete organisation feed or runtime analytics.

Related pages: [Audit project changes through automation](/docs/automation/audit-project-changes),
[Project insights](/docs/operate/project-insights), and
[Design evaluation context](/docs/flags/evaluation-context).