Monitoring Your Self-Hosted Git Server: The Four Things That Matter

Hosted Git comes with someone else’s pager. Self-hosted means the pager is yours - which is fine, as long as it only rings for real problems. Four checks cover every failure mode a small team’s Git server actually has, and none of them requires a monitoring platform you will spend a weekend configuring.

1. Is it answering?#

An external uptime check hitting the web interface every minute, from outside your network. This catches the server being down, the reverse proxy dying, and the certificate expiring. Any ping service does this for free or close to it. Alert on two consecutive failures, not one - single blips are network weather.

2. Can someone actually clone?#

The web UI can be green while SSH is dead, and your team notices at 9am Monday. A synthetic check that runs git ls-remote against a small repo every few minutes exercises the path that matters - SSH auth, Git daemon, disk read. A cron job on another machine with a dedicated read-only key (the deploy keys guide covers scoping it) is thirty lines of setup.

3. Is the disk filling up?#

Repos only grow, and a full disk corrupts things in the order you least want. Alert at 80%, not 95% - the gap between “we should prune something this week” and “pushing is failing right now.” Watch the backup destination too; it fills up quieter.

4. Did the backup actually run - and restore?#

The backup cron succeeding means a file was written, not that it restores. Backing up your Git server covers the backup half; the monitoring half is two alerts: one when the backup job misses its window, and a monthly drill where you restore to a scratch machine and clone from it. The drill is the only check on this list that cannot be automated away, and the only one that proves the rest mean anything.

Four checks, one drill, and the pager stays silent for months at a time - which is exactly what “the server is fine” should feel like.