> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryflare.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# GitHub audit reports

> Connect your organization, choose a fixed UTC window, and review cited changes with explicit coverage limits.

Flare reads GitHub Enterprise Cloud **organization web audit events** on demand and applies deterministic rules to supported changes. Each finding includes a review priority, a caveat and an exact GitHub source ID. This report does not use an AI model, build a historical baseline or save its results.

[Open GitHub audit reports in Flare](https://tryflare.ai/github-audit).

## Before you connect

* Sign in to Flare and use a GitHub account that owns the organization.
* Your organization must use **GitHub Enterprise Cloud on github.com** with organization audit API access. GitHub Free/Team organizations, Enterprise Server and dedicated `ghe.com` domains are outside this connector.
* Install **Flare Audit Log**, published by **tryflare-ai**, with **organization Administration: read**. No repository contents or write permissions are requested.
* An organization can be linked to only one Flare account at a time. Use the same Flare account when reconnecting.

You do not need to generate a personal access token, client secret or private key. Start from Flare so the installation can be linked to your signed-in account.

## Connect an organization

1. Open **Connectors → GitHub → Open GitHub audit report**.
2. Choose **Connect a GitHub organization** and select an organization you own in GitHub.
3. Review the App's read-only organization permission, then install it or select the existing installation.
4. Complete the GitHub authorization step when redirected. Flare verifies your access to the installation and performs a minimal owner audit-access check before saving the connection.
5. Back in Flare, confirm that the expected organization appears in the **Organization** selector.

If the connection attempt expires, start again from Flare. Installation links from an earlier attempt cannot be reused indefinitely.

## Choose a completed UTC window

1. Select an active organization.
2. Enter **Start (UTC)** and **End (UTC)**. The interval must be in the past, no longer than **24 hours**, and within the last **180 days**.
3. Alternatively, choose **Use last hour**, **Use last 6 hours** or **Use last 24 hours**. Presets end one minute before you select them. The populated bounds stay fixed until you edit them or choose another preset.
4. Choose **Run report** and check the returned UTC window before interpreting findings.

The start is included and the end is excluded. A window of 10:00–11:00 UTC includes an event at 10:00 and excludes one at 11:00. Finding timestamps and window labels are displayed in UTC.

Each report fetches at most **three pages or 300 web events**. GitHub is queried by the UTC dates touched by your interval, then Flare filters to the exact bounds. Other events on those dates can consume the fetch allowance. A narrower interval may therefore still have partial coverage in a busy organization.

## Read coverage before findings

| Report state           | What it means                                                                | What to do                                                                                                                               |
| ---------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Covered**            | Retrieval completed within the limits, with no quarantined events.           | Review the observed changes and their caveats. Coverage applies to this web audit query, not every kind of GitHub activity.              |
| **Partial**            | A fetch limit stopped collection or an event could not be safely normalized. | Read the limitations. Use GitHub's audit log or export for a fuller investigation; do not treat missing findings as absence of activity. |
| **No events observed** | The completed query yielded no normalized web events in the selected window. | Check the organization, UTC bounds and provider availability. This is not a verdict that the organization is safe.                       |

**Normalized** counts events Flare could interpret as valid evidence. **Quarantined** counts records it could not trust as normalized evidence. Unsupported actions can count toward coverage without producing a finding. “No supported change finding” can therefore appear even when events were observed.

## Investigate findings

The results use the same two-pane investigation layout as other Flare sources. Findings appear on the left, ordered by review priority. Expand a finding to inspect its timestamp, exact GitHub source ID and evidence caveat inline, using the same expand/collapse interaction as other sources. Audit coverage appears above the findings. The right pane contains a compact summary and predefined investigation guidance, with controls for verification steps, coverage and analysis limits. On narrow screens, findings and guidance stack vertically; section links let you move between them.

Use **Change window** to return to the organization and time controls. This clears the displayed report without fetching again. The GitHub demo uses the same layout with fictional sample logs. Connected reports show source IDs rather than raw payloads, and have no AI chat or anomaly scores.

## Supported observations

Flare reports only what the supplied event fields support. Missing transition fields do not establish the direction of a change.

| GitHub action                                 | Supported observation                                                            | Review priority |
| --------------------------------------------- | -------------------------------------------------------------------------------- | --------------- |
| `org.update_member`                           | Role changed from member to owner, when both old and new roles are present.      | High            |
| `team.add_member`                             | A member was added to a team.                                                    | Medium          |
| `org.add_member`                              | A member was added to the organization.                                          | Medium          |
| `repository_ruleset.update`                   | Enforcement changed from active to disabled.                                     | High            |
| `repository_ruleset.update`                   | Name changed while reported enforcement stayed active.                           | Informational   |
| `integration_installation.repositories_added` | An App installation gained access to at least one named repository.              | Medium          |
| `protected_branch.policy_override`            | A branch-protection policy override was recorded.                                | High            |
| `org.set_workflow_permission_can_approve_pr`  | The organization policy for Actions creating or approving pull requests changed. | Medium          |
| `personal_access_token.request_created`       | A fine-grained token access request was created.                                 | Informational   |
| `personal_access_token.access_granted`        | A fine-grained token was granted organization resource access.                   | Medium          |
| `integration.create`                          | A GitHub App was created.                                                        | Informational   |
| `integration.update`                          | A GitHub App was updated.                                                        | Informational   |
| `integration_installation.create`             | A GitHub App was installed.                                                      | Medium          |

Review priority is a triage aid, not an anomaly score or a verdict of malicious intent. For example, an App update does not establish which settings changed, and installation or expanded access does not prove the App read repository data. Compare the finding with the original GitHub audit record and your approved change records. The source ID is a citation identifier, not a link to a saved Flare report.

## Data handling and exclusions

Flare stores the installation ID, organization ID and name, the owning Flare account, verification time and connection status. GitHub user and installation tokens are transient. Audit events are not sent to an AI provider. Raw event payloads and findings are not saved; the report is lost when you leave or refresh the page, and changing the organization or window clears the displayed result.

There is no report history, automatic monitoring, schedule, deploy-webhook run, upload, baseline, numeric anomaly score or follow-up chat for this source. Git operations such as clone, fetch and push, repository contents, personal security logs and enterprise-wide audit streams are excluded. [GitHub Actions integrations](/pr-security-check) are separate from this report.

## Reconnect, disconnect and revoke access

* **Reconnect:** choose **Connect a GitHub organization** from the same Flare account and complete verification again. Restore the GitHub installation and required organization access first if they were removed.
* **Disconnect from Flare:** removes the selected connection mapping in Flare. It does not uninstall the App in GitHub.
* **Revoke provider access:** an organization owner must uninstall **Flare Audit Log** in GitHub's organization installation settings. Flare may continue to display the saved connection until a later access check fails; a saved connection is not proof the installation still has access.

## Troubleshooting

| Message or symptom                                              | Next step                                                                                                                                                                     |
| --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| No Connect control; connections are being prepared              | Refresh once and contact [Flare Support](https://tryflare.ai/support) if it persists. This indicates Flare availability, not proof that your GitHub organization is eligible. |
| Installation or organization-owner access could not be verified | Check the GitHub account, organization ownership, Enterprise Cloud API access and App permission. Start a fresh connection from Flare.                                        |
| Organization already linked to another Flare account            | Use the original Flare account, or disconnect the organization there before linking it elsewhere.                                                                             |
| Run report is disabled                                          | Select an active organization. If none is active, complete the connection or reconnect.                                                                                       |
| Choose a completed UTC window                                   | Check UTC rather than local time, start before end, a past end time, the 24-hour maximum and the 180-day retention bound.                                                     |
| GitHub access has expired                                       | Restore the installation/access and reconnect. The failed report deactivates the saved connection.                                                                            |
| GitHub rate limit reached                                       | Wait before trying again. Repeated requests may extend the interruption.                                                                                                      |
| Report could not be completed                                   | Retry later; if it persists, send Support the safe error message, organization and requested UTC bounds. Do not send tokens, private keys or raw audit records.               |

## Provider reference

GitHub documents organization-owner access and up to 180 days of audit history in [Reviewing the audit log for your organization](https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization).