Administering Keen

GitHub

Chapter 13 of 30

GitHub

GitHub collection records organisation events, repository activity, audit-log entries and feeds, so pull requests, reviews and administrative changes can stand as evidence.

Configure KEEN_GITHUB_ENABLED and its base URL as required; secret aliases include GITHUB_TOKEN and GITHUB_USERNAME. Use a token with access to the intended organisation or repositories, review upstream API quotas, and restrict repository access to the intended scope.

Collection	What it collects
`organizations`	Organisation events by default (include: events); all adds repository events through repository discovery. The organisation audit log must be selected explicitly and needs the upstream audit-log permissions.
`repos`	Repository activity.
`feeds`	Feed records.

Event payloads use github_event, audit records use audit, and feed records use feed.

Going deeper: audit-log paging and history limits

Each run collects up to 1,000 audit-log entries in time order, and a busier period continues on the next run. Audit-stream access also depends on the upstream account and permissions. GitHub API history and the adapter's bounded page reads limit what can be recovered after a long outage, and the adapter does not retrieve every repository object or full Git history.

Inspect and map evidence

Inspect a collected event and use Create mapping from this event. Structured selectors expose the payload that this source actually returns; a useful starting path is github_event → type. Action and outcome filters use Keen's normalised event values. Preview matching and non-matching examples.

For file-managed deployments, collection inputs live in config/github.yml. See the common collection workflow for UI configuration and override behaviour.