Team activity events

Team Activity presents a customer-safe history of relevant Team and App operations. The reviewing procedure is in Review Team activity.

Fields

Field	Meaning
When	Event time displayed in the viewer’s local time.
App	The affected App name, or an em dash for Team-level activity.
Who	Customer-safe actor label: current member name, former-member label, access user, or automation label.
Action	A human-readable operation, with safe context such as a repository name when available.
Result	Success, denied, error, failure, pending, or another recorded outcome.

Filters

Each column has a server-side filter: a bounded time window and searchable multi-selects for App, Who, Action, and Result. App includes No app for Team-level activity. Multiple values in one column use OR matching; selections across columns use AND matching. The option lists come from the full Team history inside the selected time window, not only the rows already loaded. Changing any filter restarts the history from the newest matching event.

Visible actions

The view includes customer-initiated and customer-relevant actions. Examples include:

• Team invitations, removals, role changes, and ownership changes;
• App creation, rename, transfer, configuration, and lifecycle actions;
• deploy, rollback, restore, maintenance, request-tracing, WAF, domain, and SSH actions;
• payment, invoice, refund, and support actions.

The exact action vocabulary grows as customer workflows are added. Use the displayed actor label, time, App, action, and result together when investigating an event.

App-level repository and configuration rows resolve App from their App resource. Restore rows use the App recorded with the restore. Deployment rows resolve App from the current deployment record when it exists. A deleted deployment may still show the Team-owned App recorded in the audit event, but its Action remains plain text. Existing deployments link to deployment detail only when the deployment belongs to a current App on the Team.

Some GitHub installation and webhook events are Team-level and therefore have no App. When a rejected push identifies a repository safely, Action includes that repository and states that it isn’t connected to an App. This makes a misfiring repository visible without exposing raw audit details. Pre-App events appear only when the GitHub installation has exactly one active Team binding; events from an installation shared by multiple Teams remain platform-scoped until an App establishes the Team.

Access and privacy

Only owners and admins can view Team Activity. The view doesn’t expose source network addresses, raw event details, private platform operations, credentials, member email addresses, or raw actor identifiers. Who resolves current members only within the selected Team; departed members and automated actions use non-identifying fallback labels. App references are also verified against the selected Team before a name is displayed or an App filter matches.

The default history window is 90 days. Customer requests can cover up to 12 months while the event remains inside the retention window.

Activity follows current App ownership. After an App moves to another Team, its customer-visible history follows the App to the new Team.