Introduced in GitLab 8.7.
Git has a built-in mechanism,
git fsck, to verify the
integrity of all data committed to a repository. GitLab administrators
can trigger such a check for a project via the project page under the
Admin Area. The checks run asynchronously so it may take a few minutes
before the check result is visible on the project Admin Area. If the
checks failed you can see their output on in the
This setting is off by default, because it can cause many false alarms.
When enabled, GitLab periodically runs a repository check on all project
repositories and wiki repositories in order to detect data corruption.
A project is checked no more than once per month. If any projects
fail their repository checks all GitLab administrators receive an email
notification of the situation. This notification is sent out once a week,
by default, midnight at the start of Sunday. Repositories with known check
failures can be found at
You can disable the periodic checks on the Settings page of the Admin Area.
If the repository check fails for some repository you should look up the error
repocheck.log file on disk:
/var/log/gitlab/gitlab-railsfor Omnibus GitLab installations
/home/git/gitlab/logfor installations from source
If the periodic repository check causes false alarms, you can clear all repository check states by
going to Admin Area > Settings > Repository
/admin/application_settings/repository) and clicking Clear all repository checks.
- For Omnibus GitLab installations, repositories are stored by default in
- Identify the subdirectory that contains the repository that you need to check.
To run a check (for example):
sudo /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/0b/91/0b91...f9.git fsck
You can also run Rake tasks for checking Git
repositories, which can be used to run
git fsck against all repositories and generate
repository checksums, as a way to compare repositories on different servers.