Skip to main content
The Activity log is a per-project record of every authenticated action taken in your project. Each entry captures who did what, from where, and exactly when, so you always have a reliable history of how the project got to its current state.

​
How activity log works

Go to the Activity log page to see every authenticated change made there, such as funnel edits, deployments, integration toggles, team and billing changes. Newest are shown first and grouped by day. Click any event to open its full detail on the right. Above the list, you can filter by event type, actor email, and date range.

​
Activity log events

​
Event details

Click an event in the list to open its full detail view. Each event shows a fixed set of fields, plus a metadata block with extra context specific to the action.

​
Fixed fields

These appear on every event:
  • Event: The machine-readable identifier for the action (for example, funnel.prototype.published). The header above shows the human label; this row is the exact code, useful when reporting an issue to support.
  • Time: When the action happened, in your local time zone, down to the second.
  • Actor: Who performed the action. Usually a teammate’s login email. For automated server events it is the system actor, and for staff-assisted actions it is a FunnelFox admin acting via impersonation.
  • IP: The IP address the request came from.
  • User Agent: The browser and device that made the request (for example, Chrome/124.0). Hover the field to see the full string.
  • Request ID: A unique fingerprint for the HTTP request that produced this event.
  • Resource ID: The id of the object the action touched (the funnel that was published, the product that was archived, and so on). Only shown for events that target a specific resource.
When the actor is a server (automated event), the IP and User Agent rows are hidden.

​
Metadata

Below the fixed fields, the Metadata block shows extra context specific to the event type. Where the fixed fields answer “who, when, from where” the same way for every event, metadata answers questions about the action itself. Examples:
  • For a published prototype: which prototype version, included variations (locales), and the publish target.
  • For a member role update: who was changed, the previous role, and the new role.
  • For a product update: which fields changed and their old and new values.
  • For a deployment: deployment id, environment, and slug.