Skip to main content

Activity

The Activity page is your workspace's audit trail: an append-only record of governance-relevant events, readable by every member. Events are written by the platform at the moment of change — there is no way to add, edit, or delete entries from the app — and event payloads are constrained to display fields, never secrets, credentials, or raw provider responses. The page header shows how many events the workspace has recorded under the active filter.

What gets recordedDirect link to What gets recorded

  • Workspace and members — workspace creation, invitations sent, re-sent, revoked, and accepted, role changes, and members disabled or removed.
  • Policies — created, drafts saved, review requested, approved, rejected, archived.
  • Catalog curation — table metadata edits, manual column classifications, classification runs, custom classification types, collections, and scenario labels.
  • Data sources — connectors created and updated, activated and deactivated, credential reads and rotations, connection tests, sync scope changes, and syncs.
  • Deployments — plans created and discarded, applies started, succeeded, or failed, and serving state published.
  • MCP tokens — issued and revoked.
  • Billing — subscription created, plan changed, updated.

Each entry shows what happened, the entity family it belongs to, who acted — a resolved member or a system badge for platform-driven events — and when, as a relative time with the exact timestamp on hover.

Reading and filteringDirect link to Reading and filtering

The timeline is grouped by day, newest first, fifty events per page. You can narrow it two ways: by entity facet — Tenant, Members, Policies, Data Sources, Billing, Collections, Scenarios — or by an exact event type. Filters are applied server-side and live in the URL, so a filtered view is shareable and safe to bookmark for recurring checks.

What to use it forDirect link to What to use it for

Change review. Before or after publishing, filter to Policies and Deployments to see exactly what changed between publications — who approved which version, and when the deployment went live.

Incident reconstruction. The trail is chronological and spans domains, so you can line up a catalog sync, a policy change, and a deployment publication into one sequence and establish what the workspace looked like at a given moment.

Agent-decision follow-up. Metatate's answers are advisory, so when an agent acts on one you'll sometimes want to trace it. Use explain_why to have the decision itself explained from the published state, then use Activity for the human history around it: who approved the policy version involved, when the current deployment publication was published, and whether the catalog changed in between.

Background jobsDirect link to Background jobs

Long-running work — data-source syncs, classification runs, deployment applies — runs as background jobs, and each job reports its lifecycle into the trail as enqueued, succeeded, or failed events. That makes the Activity page the place to confirm that queued work completed, and to spot a failed sync or apply without digging through any other surface.

RetentionDirect link to Retention

How far back the trail goes depends on your plan: the Free plan retains 30 days of activity, and paid plans retain it without limit. See plans for the full comparison. The trail is workspace-scoped — members see their own workspace's events and nothing from any other workspace.