The Site Admin dashboard provides a number of tools—described in the following sections—to help you manage your GitHub Enterprise instance.

To access the dashboard, in the upper-right corner of any page, click . Rocketship icon for accessing site admin settings

License info & search

Refer to this section of the Site Admin dashboard to check your current GitHub Enterprise license; to search for users and repositories; and to query the audit log.

Management Console

Here you can launch the Management Console to manage virtual appliance settings such as the domain, authentication, and SSL.

Explore

Data for GitHub's trending page is calculated into daily, weekly, and monthly time spans for both repositories and developers. You can see when this data was last cached and queue up new trending calculation jobs from the Explore section.

Audit log

GitHub Enterprise keeps a running log of audited actions that you can query.

By default, the audit log shows you a list of all audited actions in reverse chronological order. You can filter this list by entering key-value pairs in the Query text box and then clicking Search, as explained in "Searching the audit log."

For more information on audit logging in general, see "Audit logging." For a full list of audited actions, see "Audited actions."

Reports

If you need to get information on the users, organizations, and repositories in your GitHub Enterprise instance, you would ordinarily fetch JSON data through the GitHub API. Unfortunately, the API may not provide all of the data that you want and it requires a bit of technical expertise to use. The Site Admin dashboard offers a Reports section as an alternative, making it easy for you to download CSV reports with most of the information that you are likely to need for users, organizations, and repositories.

Specifically, you can download CSV reports that list

  • all users
  • all users who have been active within the last month
  • all users who have been inactive for one month or more
  • all users who have been suspended
  • all organizations
  • all repositories

You can also access these reports programmatically via standard HTTP authentication with a site admin account. For example, here is how you would download the "all users" report using cURL:

curl -L -u username:password http(s)://hostname/stafftools/reports/all_users.csv

To access the other reports programmatically, replace all_users with active_users, dormant_users, suspended_users, all_organizations, or all_repositories.

Note that the initial curl request to any of these reports may return a 202 HTTP response code without any other output. This is normal if there are no cached reports available; a report will be generated in the background. Once the background job has completed, you should be able to send a second request to download the report.

User reports

Key Description
created_at When the user account was created (as an ISO 8601 timestamp)
id Account ID for the user or organization
login Account's login name
email Account's primary email address
role Whether the account is an admin or an ordinary user
suspended? Whether the account has been suspended
last_logged_ip Most recent IP address to log into the account
repos Number of repositories owned by the account
ssh_keys Number of SSH keys registered to the account
org_memberships Number of organizations to which the account belongs
dormant? Whether the account is dormant
last_active When the account was last active (as an ISO 8601 timestamp)
raw_login Raw login information (in JSON format)
2fa_enabled? Whether the user has enabled two-factor authentication

Organization reports

Key Description
id Organization ID
created_at When the organization was created
login Organization's login name
email Organization's primary email address
owners Number of organization owners
members Number of organization members
teams Number of organization teams
repos Number of organization repositories

Repository reports

Key Description
created_at When the repository was created
owner_id ID of the repository's owner
owner_type Whether the repository is owned by a user or an organization
owner_name Name of the repository's owner
id Repository ID
name Repository name
visibility Whether the repository is public or private
readable_size Repository's size in a human-readable format
raw_size Repository's size as a number
collaborators Number of repository collaborators
fork? Whether the repository is a fork
deleted? Whether the repository has been deleted

Indexing

GitHub's code search features are powered by ElasticSearch. This section of the Site Admin dashboard shows you the current status of your ElasticSearch cluster and provides you with several tools to control the behavior of searching and indexing. These tools are split into the following three categories.

Code Search

This allows you to enable or disable both search and index operations on source code.

Code Search Index Repair

This controls how the code search index is repaired. You can

  • enable or disable index repair jobs
  • start a new index repair job
  • reset all index repair state

GitHub Enterprise uses repair jobs to reconcile the state of the search index with data stored in a database (issues, pull requests, repositories, and users) and data stored in Git repositories (source code). This happens when

  • a new search index is created;
  • missing data needs to be backfilled; or
  • old search data needs to be updated.

In other words, repair jobs are started as needed and run in the background—they are not scheduled by site admins in any way.

Furthermore, repair jobs use a "repair offset" for parallelization. This is an offset into the database table for the record being reconciled. Multiple background jobs can synchronize work based on this offset.

A progress bar shows the current status of a repair job across all of its background workers. It is the percentage difference of the repair offset with the highest record ID in the database. Don't worry about the value shown in the progress bar after a repair job has completed: because it shows the difference between the repair offset and the highest record ID in the database, it will decrease as more repositories are added to your GitHub Enterprise instance even though those repositories are actually indexed.

You can start a new code-search index repair job at any time. It will use a single CPU as it reconciles the search index with database and Git repository data. To minimize the effects this will have on I/O performance and reduce the chances of operations timing out, try to run a repair job during off-peak hours first. Monitor your system's load averages and CPU usage with a utility like top; if you don't notice any significant changes, it should be safe to run an index repair job during peak hours, as well.

Issues Index Repair

This controls how the Issues index is repaired. You can

  • enable or disable index repair jobs
  • start a new index repair job
  • reset all index repair state

Repos

This is a simple list of all the repositories on your GitHub Enterprise instance.

Organizations

Here you can see all of the organizations on your GitHub Enterprise instance—and even initiate an SSH key audit.

All users

Here you can see all of the users on your GitHub Enterprise instance—and even initiate an SSH key audit.

Site admins

Here you can see all of the administrators on your GitHub Enterprise instance—and even initiate an SSH key audit.

Dormant users

Here you can see—and suspend—all of the inactive users on your GitHub Enterprise instance. User accounts are considered to be inactive ("dormant") if

  • they've existed for longer than a month,
  • they haven't generated any activity within the last month, and
  • they are not Site Admins.

Suspended users

Here you can see all of the users who have been suspended on your GitHub Enterprise instance—and even initiate an SSH key audit.